Wikipedia Diskussion:Projektneuheiten/Archiv/2010

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

oder als Weblink zur Verlinkung außerhalb der Wikipedia

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

Editnotice

Als weiterführung der Diskussion vom 8. Jul. 2009 (CEST). Also zur Frage wo die Editnotice nützlich wäre. Bei der englischen Wikipedia wird beim Bearbeiten einer Vorlage eine Editnotice angezeigt welche einem darauf aufmerksam macht nach Bearbeiten der Vorlage die Dokumentation anzupassen. --helohe (talk) 15:53, 14. Jan. 2010 (CET)

Ich habe auch gerade bemerkt, dass die Editnotice auf der Diskussionsseite von Benuztern von jedermann editiert werden kann. Ich denke das war nicht so geplant. --helohe (talk) 01:30, 15. Jan. 2010 (CET)

modern-Layout - wo wurde was geändert?

Seit kurzen muss wohl etwas am modern-Skin geändert worden sein. Auf meiner Botseite starten Bot-Vorlage und Babel nicht mehr auf einer Höhe [1]. Im monobook sieht es weiterhin gut aus. Ich finde aber auch die ursächliche Änderung nicht. Merlissimo 11:26, 15. Jan. 2010 (CET)

Wo die Änderung ist, weiß ich nicht, allerdings kann man nicht sagen, dass die Box im monobook immer auf der selben Höhe ist. Ist wohl Browserabhängig (Screenshots in einigen Browsern). Bei modern ist es allerdings außer bei Chrome immer untereinander (Screens). --Steef ³⁸⁹ 20:14, 15. Jan. 2010 (CET)

Suchfeld nicht mehr streng alphabetisch

10. Januar: Die Suchvorschläge beim Tippen im Suchfeld werden nach Bedeutung (Verlinkungshäufigkeit) und nicht mehr alphabetisch sortiert angezeigt. Weiterleitungen und CamelCase werden ignoriert. Hmm, ist das schon besser so? Ich fänds alphabetisch logischer. Oder kann man das als Benutzer einstellen? --FrancescoA 19:48, 13. Jan. 2010 (CET)

Das hab ich mich heute auch gefragt. Kann man das benutzerdefiniert wieder auf alphabetische Darstellung zurücksetzen?-- · peter schmelzle · d · @ · 19:50, 13. Jan. 2010 (CET)

Derzeit: Nein. --Guandalug 19:52, 13. Jan. 2010 (CET)

Gut, dass ich da nicht alleine bin. Das ist für mich, tschuldigung, eine Verschlimmbesserung, wenn man das nicht zumindest einstellen kann. Jede Enzyklopädie oder Lexikon ist streng alphabetisch geordnet. Wenn ich Bla eingebe, kommen dann zehn willkürliche (aufgrund des neuen Algorithmus) Vorschläge daher. Bitte die Kritik nicht falsch verstehen, ich finde das Suchfeld sonst schon sehr praktisch--FrancescoA 19:57, 13. Jan. 2010 (CET)

Ich lehne diese Neuerung ebenfalls ab. So macht das ganze eher wenig Sinn... -- Chaddy · D·B - DÜP 20:16, 13. Jan. 2010 (CET)

Noch ein Vorschlag: Es wäre nett, wenn man die anscheinend fixe Zahl von 10 Vorschlägen entweder erhöhen (auf 20 vielleicht) oder benutzerdefiniert einstellen kann. Die DropDown Box könnte ebenfalls noch ein bisschen höher sein. --FrancescoA 20:01, 13. Jan. 2010 (CET)

nach abrufhäufigkeit bedeutet ja in gewisser weise, dass seiten die besonders oft gesucht werden leichter erreichbar sind. das scheint mir im vergleich zum streng klassischen Alphabetischen durchaus eine verbesserung. ... wer es gern wie "Jede Enzyklopädie oder Lexikon" mag, der kann ihn ja über Spezial:Alle Seiten gehen. das ist viel näher an der wahren klassik :D ...Sicherlich ^Post 20:36, 13. Jan. 2010 (CET)

Das Suchen bzw. eher Finden ist für mich eine zentrale Sache, die möglichst unkompliziert und flott gehen sollte. Deine Argumentationsweise kann ich auch durchaus nachvollziehen und teilzustimmen. Was viele interessiert, muss auch nicht automatisch mich interessieren. Nun weiß ich dann vielleicht auch nicht, ob der Artikel drinnen ist, wenn verschiedene Sachen ausgelassen werden. Ok, vielleicht ist es deswegen, weils neu ist, und es bewährt sich. Eine Kleinigkeit ist noch. Jetzt suche ich nach "C". Jetzt werden mir irgendwelche Begriffe vorgeschlagen. Hier ist es vielleicht sogar noch sinnvoller, weil sonst würde alles mögliche erscheinen, was mit C und Sonderzeichen kommt. Gut, wenn ich aber jetzt (Zielbegriff ist "C 64" noch ein Space tippe, ändert sich gar nichts. Eigentlich sollten schon die Vorschläge "C *" kommen. --FrancescoA 21:16, 13. Jan. 2010 (CET)

Entwerder ich haber das nicht richtig verstanden oder ihr seit auf dem Holzweg. Der neue Suchalgorytmus bietet mir Artikel an, die besonders oft verlinkt und deshalb wahrscheinlich sehr bedeutend sind. Im umkerschluss heißt dass aber auch, dass ich Artikel, die besonders selten verlinkt sind (weil z.B. neu oder relativ uninterssant) schwerer finden werden - was ich für keine Verbesserung halte. --Aineias © 21:35, 13. Jan. 2010 (CET)

oh stümmt; verlinkungshäufigkeit. naja ob das wirklich eine verbesserung ist, ist wirklich fraglich. ob es eine verschlechterung ist weiß ich allerdings auch nicht :) ...Sicherlich ^Post 21:53, 13. Jan. 2010 (CET)

Naja, es ist ja nicht so, dass man neue Artikel nicht mehr findet, sie werden bloß nicht vorgeschlagen. Benutzt diese Vorschläge jemand anders als zur Tippersparnis? Also, ich weiß schon welchen Artikel ich suche, tippe den ein und wenn er erscheint, klicke ich ihn an. --FGodard|✉|± 23:45, 13. Jan. 2010 (CET)

Ich habe mich schon etwas mit dem Thema beschäftigt und finde das Neue auch suboptimal. Man könnte ja auch die Filter nach Relevanz vornehmen, die gezeigten Ergebnisse dann aber alphabetisch sortieren. Statt der Linkhäufigkeit, gebe auch noch die Artikellänge bzw. die echten Zugriffszahlen. Solange man die Alternativen nicht untersucht hat, ob diese besser sind, halte ich den alten Weg für besser, da dieser dem Nachschlagen in einem Papierlexikon eher entspricht und somit auch von Senioren verstanden wird. --Kolossos 23:34, 13. Jan. 2010 (CET)

Die Funktion ist verwirrend und sollte dringen wieder auf alphabetisch zurückgestellt werden. Man erkennt dann sofort, das der Begriff vorhanden ist oder eben nicht, weil wir alle die Reihenfolge der Buchstaben kennen, die Häufigkeit der Verlinkungen kennen wir aber nicht. --Eingangskontrolle 10:54, 21. Jan. 2010 (CET)

Stimmt, ist mir auch als störend aufgefallen. Alphabetisch sortiert ist im Handling auf jeden Fall besser. Wer hat das eigentlich, warum geändert? Manchmal bin ich mir in der Lemmarechtschreibung nicht sicher und im Alphabet sehe ich dann die korrekte Form sofort.

Warum kommt eigentlich in solchen Diskussionen immer der Vorschlag zur Lösung des Problems einen Sonderweg ("Spezial:Alle Seiten" Sicherlich) zu nehmen. Und warum müssen solche Neuerungen immer unumkehrbar ("Derzeit: Nein."Guandalug) sein.

Führen wir jetzt ein Ranking a la Google ein? So nach dem Motto tausende haben Sepp Meier gesucht, jetzt auch Du. Gruß Retzepetzelewski 19:17, 21. Jan. 2010 (CET)

Um dieses 'Nein' noch mal auszuführen: Es gibt aktuell keine Option, diese Änderung benutzerdefiniert zurückzunehmen. Umgestellt haben die Suche die Wiki-Entwickler, siehe auch die Informationen auf WP:NEU, wo solche von den Entwicklern eingeführten Änderungen berichtet werden. --Guandalug 19:27, 21. Jan. 2010 (CET)

Es ist aber ziemlich sinnlos, wenn die lieben Entwickler an der Community vorbeientwickeln. Das müsste deutlich besser abgestimmt werden... -- Chaddy · D·B - DÜP 19:44, 21. Jan. 2010 (CET)

Schon wieder läuft die Diskussion an zwei Stellen, siehe also auch Wikipedia:Fragen zur Wikipedia#Ausklappdingsbums im Suchfeld, -jkb- 19:36, 21. Jan. 2010 (CET)

Ich finde die neue Methode gut. Ich finde schneller, was ich suche. --Drahreg·01^RM 19:54, 21. Jan. 2010 (CET)

Tatsächlich? Suchst du mal Berlin in New York: Bei Berlin (N geht es mit Berlin-Neukölln los. Sinnvoll? Schneller? Wieso setzt AJAX die Kombination von Leerzeichen und Klammer (Standard bei BKLs) bei der Suche mit einem Bindestrich gleich? Das ist definitiv nicht durchdacht. Außerdem sollte die BKL grundsätzlich an erster Stelle stehen und nicht an letzter (weil normalerweise nicht verlinkt). --Matthiasb 19:54, 22. Jan. 2010 (CET)

Ich wäre auch dafür, den bug, der ein feature zu sein behauptet, pronto zurückzusetzen. Ich bin jedesmal verwirrt, wenn ein Begriff erscheint, der alphabetisch nach dem von mir Gesuchten liegt, weil ich dann denke, den gesuchten Begriff gibt es nicht und erstmal schaue, ob ich mich nicht vertippt habe. --Mogelzahn 23:39, 22. Jan. 2010 (CET)

Hier kriegt das aber keiner von den Entwicklern mit. Wen löchert man damit am besten? DaB. vielleicht? -- Chaddy · D·B - DÜP 23:54, 22. Jan. 2010 (CET)

Ich mags auch nicht. Muss jetzt z.B. wirklich mehrmals durch "Alle Artikel" flöhen wenn ich bei meiner "Abkürzungsarbeit" suche obs die gleiche Abk. in verschiedenen Groß- und Kleinschriebungsvarianten z.B. als Weiterleitungen auf unterschiedliche Artikel gibt. Ich wag aber nicht zu beurteilen wie die Neuerung beim gemeinen Nur-Leser ankommt. Gibts da z. B. im OTRS irgendwelche Meldungen zu? Wurde das eigentlich nur auf de: eingeschaltet oder "weltweit" und wenn dann müsste es doch auf meta oder so eigentlich eine Diskussion darüber existieren, nur wo? Meta is leider nich so mein Ding. --JuTa Talk 00:02, 23. Jan. 2010 (CET)

Es ist Wikimedia-weit aktiv, in Wikt und WQ ärgert mich der Unsinn auch grad tierisch. Vor allem da bei Wikt zwischen Groß- und Kleinschreibung unterschieden wird, sucht man sich nun tot. --Stepro 02:45, 23. Jan. 2010 (CET)

Ich habe alle Tickets an info-de der letzten 2 Wochen nach den Stichwörten „Suche“, „Suchfeld“, „alphabetisch“ und „alfabetisch“ durchsucht. Es gab genau 1 E-Mail zu dem Thema, in der ein Kunde nachgefragt hat, ob die Sortierung kaputt sei. Ohne weitere Wertung seitens des Kunden. Allgemein habe ich auch sonst keine Aufregung zu dem Thema mitbekommen. Weder in den relevanten tech-Chats noch auf der wikitech-Mailingliste. Meine subjektive Schlussfolgerung: Entweder merkt es der Leser nicht oder er freut sich, dass er schneller zum Ziel kommt. Ich persönlich mag die Funktion übrigens auch :-)

@Stepro: Ich kenne den Code nicht, er wurde in Java geschrieben. Ich kann daher nicht sagen, ob die Besonderheiten von Projekten, die zwischen Groß- und Kleinschreibung unterscheiden, berücksichtigt wurden. Sprich am besten mal den Programmierer Robert Stojnic im #mediawiki-Chat an. Er ist dort unter dem Nick rainman recht häufig anwesend. — Raymond ^Disk. 07:44, 23. Jan. 2010 (CET)

Hallo Raymond, ich fühle mich von diesen Neuerungen immer schrecklich überfahren. Wenn man dann nachhakt "warum?, wieso?, weshalb?, ist es zurückzusetzen?" wirst Du auf umständliche Ausweichmethoden hingewiesen oder es heißt lapidar Derzeit Nein oder wende Dich an den. In der Regel heißt es dann "Vogel friss oder stirb" und ich stehe wieder da mit meinem Schmalspurwissen. Gruß Retzepetzelewski 14:20, 23. Jan. 2010 (CET)

Hast du einen Vorschlag, was verbessert werden könnte? Welche Erwartungen hast du? Die Seite WP:NEU kennst du? Das Wikimedia Technical Blog ist auch sehr lesenswert. — Raymond ^Disk. 16:11, 23. Jan. 2010 (CET)

Wenn man wegen jeden Kleinscheiss als Programmierer die Community fragen würde, käme man nicht mehr zum Programmieren. Auch ich finde die Neuerung als eine Verschlechterung, mich interessiert die Verlinkungshäufigkeit z.b. absolut gar nicht. -- mj ⌫⌧⌦ -- 19:46, 23. Jan. 2010 (CET)

Gibt es eigentlich irgendwo den javascript-code für die bisherige, alphabetische Darstellung der Such-Fundstellen? -- · peter schmelzle · d · @ · 14:42, 23. Jan. 2010 (CET)

Das dürfte mwsuggest.js sein. — Raymond ^Disk. 16:11, 23. Jan. 2010 (CET)

Thx. Wenn ich das richtig sehe, wurde das in 1.13.0 eingeführt und wird dort mit $wgEnableMWSuggest=true aktiviert. Die aktuellen Suchvorschläge-Syntax kam mit 1.16.0 und wird dort mit $wgEnableOpenSearchSuggest=true aktiviert.Je nachdem, wer am Drücker (der localsettings.php) sitzt, kann man also sehr wohl das eine oder das andere aktivieren, weil es sich um zwei völlig unterschiedliche Funktionen handelt, oder?-- · peter schmelzle · d · @ · 17:05, 23. Jan. 2010 (CET)

Ich fände es schön, wenn solche gravierenden Änderungen nicht weltweit, sondern projektweise eingeführt würden und zum Anderen dann den jeweiligen Projekten auch die Möglichkeit gegeben würde, so etwas im jeweiligen Projekt vorher zu diskutieren. Mich behindert es in meiner Arbeit jedenfalls erheblich und ich finde, daß es sich um eine deutliche Verschlechterung handelt. --Mogelzahn 18:15, 23. Jan. 2010 (CET)

Was das für ein Murks ist, erkennt man, wenn man G eingibt. Ist Gesang wirklich das wichtigste Wort, das mit G anfängt? Wer Geo eingibt, erwartet Artikel zu Geographie oder meinetwegen zu George W. Bush – dem schlagen wir die Georg-August-Universität Göttingen vor – vermutlich deswegen, weil das Ding in irgendeiner Vorlage zigtausendfach verlinkt wird. Die Verlinkungshäufigkeit sagt gar nix zu Wichtigkeit aus. Daß Gesang vor Geographie kommt, ist Unfug³. --Matthiasb 20:54, 23. Jan. 2010 (CET)

Wieso trampeln wir hier eigentlich immer noch auf der Stelle? Es ist doch nicht zu übersehen, dass zahlreiche Benutzer das für Murks halten. Warum aber interessiert das dennoch niemanden? Raymonds Antworten helfen leider gar nichts weiter... -- Chaddy · D·B - DÜP 00:30, 24. Jan. 2010 (CET)

Weil von uns niemand in der Lage ist, auf Bugzilla einen vernünftig formulierten Bug aufzumachen, der nicht gleich als Getrolle schnellerledigt wird. --Matthiasb 11:36, 24. Jan. 2010 (CET)

Nobody likes a change ('xept a wet baby). Als sie das Suchfeld ganz nach oben setzten, war das genial. Die De-Alphabetisierung ist verwirrend, unpraktisch und unlogisch (weil ich etwa 10 verschiedene "gewichtete" Kriterien nennen könnte, je nach gusto). Enzyklopädien sortieren alphabetisch. Wie sähe der Brockhaus aus, wenn man nach "Vokabularhäufigkeit" oder "Artikellänge" oder "Auch sonst noch vorhandenen Stichworte" oder "Aktualität" sortieren würde?? Unausgegorener Schwachsinn² !!! G! G.G. ^{nil nisi bene} 10:38, 26. Jan. 2010 (CET)

Suchen wie im Brockhaus :oD ...Sicherlich ^Post 10:45, 26. Jan. 2010 (CET)

Fast richtig, nur möchte ich das Mediawiki es mir erspart, mich durch die einzelnen "Bände":

Alvaro Gaxiola	 bis 	André Huebscher
André Hughes	bis 	Apolipoprotein E
Apolipoproteine	bis 	Aschenbeck

klicken zu müssen; Spezial:Alle_Seiten als Startseite zur Wikipedia wäre natürlich auch möglich. Die Kritik lautet: Wir sind hier nicht bei Google, das mehr oder weniger zwangsläufig mit dem Ranking arbeiten muss, um Spreu und Weizen zu trennen. Nase hoch: Bei uns hier ist alles Weizen ;-) --Ska13351 19:30, 26. Jan. 2010 (CET)

Sonderzeichen

Die neue Suche findet auch Sonderzeichen anhand der Ersatzschreibweise. Damit könnten die ganzen Weiterleitungen für Sonderzeichen entfallen. --Fomafix 21:44, 13. Jan. 2010 (CET)

nein; vermeidet doppelanlagen und ich bevorzuge es bei Lodz auch gleich anzukommen wo ich ankommen will ...Sicherlich ^Post 21:53, 13. Jan. 2010 (CET)

Es wird nicht nur über die Suche gesucht. --FGodard|✉|± 23:46, 13. Jan. 2010 (CET)

Bitte nicht. Ich verstehe nicht ganz, wieso ihr immer die ganzen Redirects löschen wollt (ok, Klammerredirects sind wirklich nutzlos). Aber ansonsten sind Redirects ein sinnvolles Mittel, um die Auffindbarkeit und die Verlinkbarkeit zu verbessern. -- Chaddy · D·B - DÜP 23:52, 13. Jan. 2010 (CET)

Wer kein Javaskript aktiviert hat, hat auch kein AJAX und braucht deswegen Lodz, ganz einfach. --Matthiasb 19:50, 22. Jan. 2010 (CET)

Und nicht jeder der JS aktiviert hat, benutzt das Suchfeature der WP. Das erspart einem nebenbei auch, sich über das neuste Bugture ärgern zu müssen. ;) Ich suche per URL, Special:Prefixindex (wenn ich mal wieder gezielt am Lemma vorbeirate) oder Google, die ersten beiden scheitern ohne Redirs. Brot fressen die Redirs auch nicht. Deshalb: Dagegen. Viele Grüße, —mnh·∇· 04:55, 23. Jan. 2010 (CET)

Google erkennt auch noch nicht _alle_ Umschreibungen. Irgenwann hatte ich mich bei einem Zeichen gewundert. Ich glaub es war was nordisches. Isländisch? Keine Ahnung mehr. Und dadurch, dass die Suche per URL bei den Browsern dabei ist, verwenden dies einige. --Franz (Fg68at) 17:08, 23. Jan. 2010 (CET)

Umlaute

Ich hab ein wenig den Eindruck, dass die Vorschläge, die angeboten werden, sehr auf Benutzer einer englischen Tastatur ausgerichtet sind: Tippt man beispielsweise die Buchstaben 'Fü' ein, werden einem folgende Artikel angeboten: Fußball, Fußball-Bundesliga, Fußball-Weltmeisterschaft 2006, Fußballverein, Fußballtrainer, Fulda, Fußball-Weltmeisterschaft, Fußball-Weltmeisterschaft 2002, Fußball-Europameisterschaft 2008. Viel Fußball und eine Stadt... jedoch kein einziger Begriff der mit Fü anfängt. Um auf Artikel mit Fü am Anfang zu stoßen, muss man Fue eingeben, da bleibt der Fußball außen vor. Letzteres lässt mich vermuten, dass da prinzipiell schon an Umlaute, Accents etc. gedacht wurde, aber nur in der Form, dass jemand, der diese nicht auf der Tastatur hat, durch die übliche Umschreibung (ü -> ue, ß -> ss, ...) doch zu seinem Ziel hat. Aber für denjenigen, der die Zeichen zur Verfügung hat, ist dies nicht hilfreich, da die Umlaute einfach wie der zugehörige Vokal (ü -> u, ...) einsortiert wird. Das mag, wie eingangs erwähnt, sinnvoll für die klassische qwerty-Tastatur sein, für die Benutzer 'lokalisierter' Tastaturen arbeitet die Vorschlagsliste leider sehr unintuitiv und unlogisch. Halte ich für einen respektablen Usability-Flaw. --Gnu1742 22:32, 23. Jan. 2010 (CET)

Noch so ein Murks: Sortierung, die DIN widerspricht, sondern nach den "Telefonbuchregeln" sortiert. Das hat ja sogar DOS 5.0 richtig beherrscht. --Matthiasb 11:36, 24. Jan. 2010 (CET)

Es gibt nix gutes außer man tut es, daher hab ichs mal als #22272 ins Bugzilla eingekippt. --Gnu1742 11:30, 26. Jan. 2010 (CET)

...ich halte die sog. telefonbuchsortierung(latin1_german2_ci im MySQL-sprech) immer noch für angebrachter in einem nationalen wiki: "Fü" wird behandelt wie "Fue" und das macht auch sinn. wurde schließlich eben darum extra entwickelt - weil der normalbürger auch so denkt und sucht! DOS war halt englisch orientiert, eine der wenigen sprachen ohne jegliche umlaute, akzente etc. ... da kann man diese 'wörterbuchsortierung'(latin1_german1_ci; nach welcher "Öl" hinter "Ofen" kommt!) getrost als "alten zopf" abhaken ;) ... das schlimme iss, daß die wiki-software keine der beiden sortierungen anwendet - sondern die 'sortierung nach UTF8' - in den kategorien wirds deutlich: da kommt dann "Österreich" hinter "Zimbabwe", weil alle umlaute ans ende gesetzt werden... frei nach dem motto simplify your(naturally American way of) life! gruß, --ulli purwin _fragen? 13:42, 27. Jan. 2010 (CET)

Welcher Normalbürger sucht bitte nach "Fue", wenn er "Fü" meint? Kein Normalbürger würde auf die Idee kommen, da erst eine komische Transkription der deutschen Wörter auf irgendeinen englischen Tastaturstandard anzuwenden, um das Suchfeld benützen zu können. --თოგო^{D ♇} 17:19, 27. Jan. 2010 (CET)

Ich z.B. hab leider kein ü standardmaessig auf der Tastatur.--Meisterkoch Rezepte bewerten! 17:55, 27. Jan. 2010 (CET)

Eben drum soll ja 'Fü' wie 'Fue' behandelt werden.... damit es egal ist, ob jetzt ein Umlaut-Nutzer oder ein Umlaut-Ersatzschreibung-Nutzer dran ist.... --Guandalug 17:48, 27. Jan. 2010 (CET)

Aufklappfeld und Buttons

Etwas, was nur über die Suche geht, ist die Volltextsuche. Vor allem dazu verwende ich das Feld. Es ist schön, dass Lemmas in einer ausklappbaren Liste angezeigt werden. Aber um auf den Button "Volltext" zu kommen, muss ich jetzt oft einmal daneben hinklicken, damit die Liste verschwindet und der Button sichtbar wird. Kann man nicht die Liste nach oben klappen, oder die Buttons oben anordnen? --Franz (Fg68at) 03:22, 28. Jan. 2010 (CET)

Ich fürchte nicht. Für das „nach oben“-öffnen gibt es _meines Wissens_ keine standardisierte Option, ich glaub auch nicht, dass sich das per Javascript als Dreizeiler machen lässt. Die andere Idee, Buttons nach oben ist zwar interessant, beißt sich aber mit einem Usabilityprinzip: logische Funktionsgruppen (hier Funktion „Suchen“) sollten immer nach dem Lesefluss angeordnet werden – sprich: das Suchfeld, dass der Benutzer zuerst braucht, sollte (links) oben sein, wo es der Benutzer bei normalem Lesen als Erstes findet. Die abschließenden Interaktionselemente hingegen (rechts) unten. Mir fällt außer strikt horizontaler Anordnung auch leider keine Lösung ein. :( Viele Grüße, —mnh·∇· 03:45, 28. Jan. 2010 (CET)

Statt daneben zu klicken sollte auch ESC helfen. Mit Firefox geht es auch noch bequemer per Search-Addon + Schlüsselwort. Merlissimo 03:53, 28. Jan. 2010 (CET)

Klar, ESC löst das Problem mit der als störend empfundenen zusätzlich erforderten Aktion bloß nicht, es ist ja selbst eine. Viele Grüße, —mnh·∇· 04:48, 28. Jan. 2010 (CET)

Allerdings existiert dieses Problem schon länger, meine ich, ich "klicke daneben" schon eine Ewigkeit :-) -jkb- 09:30, 28. Jan. 2010 (CET)

Ja, und nervt auch schon länger… :-) --Leyo 09:45, 28. Jan. 2010 (CET)

+3 G! G.G. ^{nil nisi bene} 09:57, 28. Jan. 2010 (CET)

Hallo, wo die ausgeklappte Liste angezeigt wird, entscheidet der Browser abhängig vom umgebenden Platz. Um die Volltextsuche auszulösen, braucht man nicht einmal das Eingabegerät zu wechseln. Mit der Tastenkombinationfolge Tab Tab Leer sollten in gängigen Browsern die Liste verschwinden, der Fokus auf die Schaltfläche [Volltext] gehen und der Suchbegriff verschickt werden. --Wiegels „…“ 12:22, 28. Jan. 2010 (CET)

? habe nur eine Tab-Taste. Brauche ich eine neue Tastatur? :-) -jkb- 12:25, 28. Jan. 2010 (CET)

Mit Nacheinanderdrücken von Tab Tab Leer ... (unter Tastenkombi verstehe ich gleichzeitig drücken) - guter Tip! -jkb- 12:27, 28. Jan. 2010 (CET)

Verschiebung

Mir fällt gerade auf, das wenn man einen Artikel verschieb folgender Text kommt:

Wenn die Weiterleitung vom alten Titel gelöscht werden soll (z. B. wegen eines Schreibfehlers oder weil eine andere Seite dorthin verschoben werden :soll), stelle sicher, dass keine Links mehr auf die alte Seite zeigen, und füge dort am Anfang ein:

{{Löschen}}

Kurze Begründung -- ~~~~

Die Seite wird dann von einem Administrator gelöscht.

Sollte da aber nicht eher:

{{Löschen|Kurze Begründung -- ~~~~}}

stehen? --Calle Cool 10:15, 11. Feb. 2010 (CET)

Kommt auf das gleiche hinaus. Probiere's irgendwo in der Vorschau-Ansicht aus. -jkb- 10:19, 11. Feb. 2010 (CET)

{{Löschen}} ist gewissermaßen die „Old School“-Variante, der Parameter der Vorlage ist erst irgendwann 2006/7 dazugekommen (und imo auch ziemlich nutzlos). Viele Grüße, —mnh·∇· 15:07, 11. Feb. 2010 (CET)

Stimmt wäre nur eine kosmetische Änderung.--Calle Cool 15:08, 11. Feb. 2010 (CET)

Die Variante mit Parameter ist zu bevorzugen, weil damit direkt die Sperrbegründung für Admins ausgefüllt wird. Dann brauchen wird uns bei der Löschung nichts mehr ausdenken. ;-) Merlissimo 15:22, 11. Feb. 2010 (CET)

Wäre es viel Aufwand das in der Software zu ändern? Vorteil/Parktisch wäre dann, das man es einfach Makieren und Kopieren kann. Würde etwas Tipparbeit sparen ;-) für Admin´s und user ;-)--Calle Cool 15:28, 11. Feb. 2010 (CET)

Hatte ich doch schon längst (92 Sekunden) vor deiner letzten Antwort hier erledigt ;-). Merlissimo 15:35, 11. Feb. 2010 (CET)

Die Begründung wird bei mir auch bei der Variante ohne Parameter übernommen, ich glaube es wird alles bis zum Ende des Zeitstempels übernommen. --Engie 15:33, 11. Feb. 2010 (CET)

//mit BK // Eben. Und wenn ich die Begründung im Fall 2 vergesse, tue ich es auch im Fall 1... Gruss -jkb- 15:36, 11. Feb. 2010 (CET)

@Engie Wenn du nicht den Vorlagenlink benutzt oder die Begründung leer ist, nimmt Mediawiki die ersten Zeichen, soweit sie hineinpassen. Also inklusive Vorlagenname und nachfolgendem Artikeltext, wenn die Begründung zu kurz war. Leider passieren da auch Unfälle, wenn der Artikeltext plötzlich sichtbar wird. Deswegen ist mit Parameter sicherer. Merlissimo 15:45, 11. Feb. 2010 (CET)

Interessanter Diff

Hi, dies keine Diskussion zu einer Projektneuheit, aber ich bin auf einen interessanten diff gestoßen. Um 10:06:09 Uhr schützt Complex die Seite (mit [edit=sysop]). In der gleichen Sekunde, aber danach, wurde die Seite von einem Nichtadmin bearbeitet. Dies ist eigentlich nicht möglich, da die Seite ja von Complex geschützt wurde.

Wenn man sich den Code anschaut (Funktion updateRestrictions), dann sieht man, dass zuerst die restrictions table (l. 2383) geupdated wird, und dann der Nulledit in der Versionsgeschichte hinzugefügt wird (l. 2398). Die beiden SQL-Statements werden nicht (wie man es vielleicht ganz sauber programmieren würde) in einer Transaktion ausgeführt. Anscheinend (so erkläre ich mir das jedenfalls) wurden die SQL-Statements parallel ausgewertet, und obwohl das restrictions-Statement zuerst kam, wurde zuerst der Nulledit eingefügt, und danach, aber bevor die restrictions-Tabelle geupdated wurden, wurde die Abfrage ausgeführt, ob PassePorte die Seite bearbeiten kann.

Und die Moral von der Geschicht'? Traue deinem DBMS nicht! (Oder benutze Transaktionen, wenn Atomizität wichtig ist (was in diesem Fall nicht zutrifft)). Gruß, --Church of emacs D B 20:06, 11. Feb. 2010 (CET)

Es gibt einen lustigen Bug, wie man als Nicht-Admin sogar Minuten später noch einen Edit erzeugen kann. Merlissimo 20:11, 11. Feb. 2010 (CET)

Wie, wie, wie??? ;-) Ist vielleicht ´n Bug-Report fällig? (also in diesem Fall) --Wahresmüsli ^Hier_{kannst du deine Milch dazugeben} 20:20, 11. Feb. 2010 (CET)

(BK) Tatsächlich? Ist der öffentlich/den devs bekannt/gefixt/etc.? --Church of emacs D B 20:22, 11. Feb. 2010 (CET)

Atomizität ist doch verdammt schwer zu bewerkstelligen auf einem verteiltem DBMS. Wenn man Locks für’s Lesen (der User-Prioritäten zB) acquired, kommt man eh direkten Weges in die Hölle … :-) Gruß, --Revo Echo der Stille 20:47, 11. Feb. 2010 (CET)

Fehler bei der Eingabe von Sonderzeichen

Seit der letzten Softwareänderung gestern Abend verändert sich beim Firefox 3.5 die Scrollposition des Eingabefeldes, wenn über die Sonderzeichenleiste unter dem Eingabefeld Zeichen eingegeben werden. Außerdem funktioniert die Eingabe von Sonderzeichen in die Zusammenfassungszeile nicht mehr. Bitte schleunigst wieder zurücksetzen. --Fomafix 10:38, 10. Feb. 2010 (CET)

Datenpunkt: mit Gecko/2009122116 Firefox/3.0.17 nicht reproduzierbar. —mnh·∇· 11:01, 10. Feb. 2010 (CET)

Zur Eingabe von Sonderzeichen in die Zusammenfassungszeile habe ich Bug 22460: Charinsert into the summary fields does not work aufgemacht. — Raymond ^Disk. 11:57, 10. Feb. 2010 (CET)

Weitere Besonderheit mit Internet Explorer: Wenn ich mit den Edittools eine Unterschrift einfüge, dann hüpft der Cursor aus dem Bearbeitungsfeld. --tsor 11:37, 10. Feb. 2010 (CET)

Beim Internet Explorer 6 bewegt sich der Cursor zusätzlich nach jedem Einfügen um ein Zeichen nach rechts. Eingabe in die Zusammenfassungszeile geht auch nicht. --Fomafix 12:29, 10. Feb. 2010 (CET)

Hat zwar mit dem Problem nichts zu tun, aber wieso verwendet ihr noch so uralte Browser (IE 6 und FF 3.0)? Auch der FF 3.5 ist nicht mehr aktuell... -- Chaddy · D·B - DÜP 21:55, 10. Feb. 2010 (CET)

Weil die 3.0.x-Linie gerade mal 1½ Jahre alt ist, noch gepflegt wird und hier gut funktioniert, während ich zu 3.5 bis heute Probleme sehe, die ich schlicht nicht habe. (Siehe oben. ;) Danke, cutting edge brauch ich nicht, ich ziehe in jeder Hinsicht Stabilität vor. Viele Grüße, —mnh·∇· 06:29, 11. Feb. 2010 (CET)

Das Problem mit dem IE6 ist, dass er noch sehr oft in Firmennetzwerken im Einsatz ist. Hätte ich es nicht selber Ende letzten Jahre bei zwei wirklich großen Konzernen gesehen, so würde ich es auch nicht glauben. Die Mitarbeiter fluchen, dürfen und können sich aber keine Alternativen installieren :-( — Raymond ^Disk. 16:22, 11. Feb. 2010 (CET)

Man kann nicht einmal eine exe-Datei von einer Portablen Version von z.B. Firefox starten. Auch das ist bei vielen Firmen technisch unterbunden. -- Steffen2 18:18, 11. Feb. 2010 (CET)

Jetzt scheint alles wieder normal zu funktionieren – auch beim Internet Explorer 6. Danke. --Fomafix 10:14, 16. Feb. 2010 (CET)

Zwingender User-Agent?

Zu dieser Änderung: Ich kann nicht nachvollziehen, warum RFC 2616, 14.43 verletzt werden muss. Abgesehen davon, scheint das wieder deaktiviert worden zu sein. Ich konnte jedenfalls gerade eben de-wp und en-wp ohne User-Agent lesen. --AFBorchert 09:29, 16. Feb. 2010 (CET)

Der Grund war wohl eine "Horde" von crawlern / Computern, die eine permanente Grundlast auf den WP-Servern verursachte, alles über API, und das ohne UA. So jedenfalls klang die "Performance-Optimierungs-Session" gestern abend im Tech-Chat. --Guandalug 09:43, 16. Feb. 2010 (CET)

PS: Diese Änderung betrifft meines Wissens nur die API-Schnittstelle. --Guandalug 09:44, 16. Feb. 2010 (CET)

Bei der API kann ich das in Grenzen nachvollziehen, bei der normalen Browserschnittstelle darf das imho nicht sein. --Purodha Blissenbach 17:43, 3. Mär. 2010 (CET)

Dumm nur, dass die Suche anscheinend (teilweise) auch betroffen ist... --Guandalug 18:12, 3. Mär. 2010 (CET)

Welche Suche? Wenn du einen Browser ohne UA verwendest, erhälst du nix, gar nüscht, auch kein Suchfeld. Andererseits: Wer verwendet schon einen Browser mit leerem UA? — Raymond ^Disk. 18:32, 3. Mär. 2010 (CET)

Es könnte sein, dass zB Privoxy den UA frisst. Aber wenn man das verwendet, muss man auch mit so etwas rechnen, schätze ich. Gruß, --Revo Echo der Stille 18:35, 3. Mär. 2010 (CET)

Mein Privoxy frisst nix, den tät ich schlagen, wenn er's täte. Aber diverse Anfragen beim Support-Team lassen vermuten, dass es da zu Problemen kommt. --Guandalug 18:37, 3. Mär. 2010 (CET)

WikiSets

Der Link http://meta.wikimedia.org/wiki/Special:WikiSets für jederman scheint nicht zu funzeln, der Link für Stewards ist wohl http://meta.wikimedia.org/wiki/Special:EditWikiSets mit "Edit" hinzu. -jkb- 09:52, 16. Mär. 2010 (CET)

Daran sollte es hängen: "Diese Softwareänderungen sind real soon now zu erwarten, sie sind noch nicht live " ;-) -- Benzen ^C₆H₆ 10:17, 16. Mär. 2010 (CET)

Ja sicher, Vorschau, klar... mich irritierte eben dass die Seite EditWikiSets zu funktionieren schien (nun bin ich kein Steward und bekam eben eine Meldung über nicht ausreichende Zugangsrechte, aber sonst schien es als ob...). Na gut. Danke und Gruß -jkb- 10:27, 16. Mär. 2010 (CET)

Liegt daran, das es die Seite EditWikiSets schon länger gibt. Sie wurde nun umbenannt und ihr Inhalt für alle sichtbar. Der Umherirrende 18:28, 16. Mär. 2010 (CET)

Vorwarnung

*schauder*. Okay, schon mal alle festhalten, neue Bugs im Anrollen ;) --Guandalug 18:11, 17. Mär. 2010 (CET)

Ist das nicht ein Fall für die „Mobile Infanterie“? liesel 18:15, 17. Mär. 2010 (CET)

Dann Ciao bis zum nächsten Jahreswechsel, vielleicht geht's dann schon wieder :-) ("kurze" Wikiferien sind ja angeblich gut fürs Gemüt) -jkb- 18:26, 17. Mär. 2010 (CET)

Hoffentlich haben die Entwickler/Projektverantwortlichen gelernt und geben es noch nicht live. Der Umherirrende 20:53, 17. Mär. 2010 (CET)

Gestern Abend, gegen 23:00 traten plötzlich altbekannte Bugs (ungewollte Schriftformatierung, ungewollte Zeilenumbrüche bzw. -zusammenfügungen) wieder auf. Ich habe darauf Beta für mich abgeschaltet. Später am Abend (nun wieder in Beta) war der Spuk wieder vorbei. Ob Bugfix oder Revert auf Vorversion kann ich nicht sagen. --Spischot 12:15, 18. Mär. 2010 (CET)

Na toll - und prompt wird beim Einfügen von Text, der neben Text auch im HTML-Format verfügbar ist (z.B. durch Kopieren aus dem Browser), die HTML-Formatierung für einen Augeblick angezeigt und anschließend der Text neu umbrochen. :-((( --Spischot 09:19, 25. Mär. 2010 (CET)

ich würde mich mehr freuen, wenn "MediaWiki 1.17 alpha" aktiv wird. Der Umherirrende 20:53, 17. Mär. 2010 (CET)

Wäre es, wenn es denn nun Standard wird, nicht an der Zeit, das Ding auch in Spezial:Einstellungen mit seinem Eigennamen 'Vector' zu bezeichnen und nicht mit dem vollständig unnötig eingedeutschten 'Vektor'? Alternativ wird es einen Anfrage-Tsunami auf FZW und OTRS geben, warum denn die persönliche 'vektor.css' nicht gefunden. --Gnu1742 11:20, 30. Mär. 2010 (CEST)

Ebenfalls Vorschlag zu Einstellungen: in dem Kasten mit "Ab Ende April 2010 wird der Standardskin auf Vektor umgestellt. Benutzer, ..." könnte man den Text ändern in "... der Standardskin Monobook auf ...", es wird deutlicher, und von den vielen die Monobook haben wissen nicht dass es eben der jetzige Standardskin ist. -jkb- 11:30, 30. Mär. 2010 (CEST)

Der Skin Kölnisch Blau heißt allerdings auch Kölnisch Blau und nicht "Cologne Blue". Das dürfte also gar kein Problem darstellen. -- Prince Kassad 11:32, 30. Mär. 2010 (CEST)

Dürfte von daher ein Problem sein, weil Kölnisch Blau mit abstand nie so häufig genutzt wurde wie Vector schon jetzt und erst recht in Zukunft. Ebensowenig ist Monobook jemals in Einzelbuch übersetzt worden. Von eventuellen Verständigungsproblemen in der Kommunikation mit non-de-Leuten abgesehen. --Gnu1742 12:13, 30. Mär. 2010 (CEST)

Der Standardskin ist doch mit (Voreinstellung) markiert, natürlich könnte man trotzdem den Satz um das Wort ergänzen. Der Umherirrende 16:14, 30. Mär. 2010 (CEST)

Richtig, das sehe ich aber erst wenn ich den Reiter Aussehen öffne. Sonst eben nicht. -jkb- 16:47, 30. Mär. 2010 (CEST)

Transparente Hintergrundfarbe bei mathematischen Formeln

Seit heute ist eine transparente Hintergrundfarbe bei mathematischen Formeln aktiv. Neue Formeln werden nun korrekt mit transparentem Hintergrund gerendert: $E=m\cdot c^{3}$. Bestehende Formeln, die im Cache sind, haben noch die weiße Hintergrundfarbe: $E=m\cdot c^{2}$. Kann der Cache (nach und nach) geleert werden, damit die Formeln mit transparentem Hintergrund neu generiert werden? Ansonsten besteht die Gefahr, dass eifrige Autoren die Formeln in Artikeln unsichtbar ändern, nur um das generieren neu anzustoßen: $E=m\cdot c^{2}$ --Fomafix 14:16, 9. Apr. 2010 (CEST)

In Artikeln sollte es eigentlich nicht stören, da dort der Hintergrund standardmäßig weiß ist. Ich frage mich aber gerade, wie man überhaupt die math-Bilder aus dem Cache löschen kann. Die Server-Admins wird man wohl dazu nicht bringen können. Dein Beispiel ist übrigends (bei mir) nicht mehr mit weißem Hintergrund. Der Umherirrende 16:37, 9. Apr. 2010 (CEST)

Ich glaube, das geht nur, wenn man die Formel bearbeitet und sie (minimal) ändert, so dass sich ein Hashwert ändert. Ich glaube auch nicht, dass die Serveradmins nur aus diesem Grund den Cache (nach und nach) leeren. Zuviel Last. Ich erinnere mich an einen echten Bugfix, bei dem ein Teil des Caches gelöscht werden musste. Sie taten sich schwer damit... — Raymond ^Disk. 16:41, 9. Apr. 2010 (CEST)

Gerade das manuelle Ändern der Artikel und damit des Hashwertes wollte ich vermeiden. Jetzt ist mein Beispiel bei mir auch mit transparentem Hintergrund. Anscheinend ist es bereits neu redendert. Hoffentlich werden die übrigen Bildchen auch nach und nach neu gerendert. --Fomafix 16:47, 9. Apr. 2010 (CEST)

common.css/js

Da es ja einige Verwirrung gab. „(Softwareneuheit) Persönliche Styles und Skripte können skinübergreifend in User:<name>/common.css bzw. User:<name>/common.js definiert werden (Bug 10183)“ ist doch auch noch nicht live, oder? Zumindest funktioniert es nicht und wird auch nicht als <link rel="stylesheet" … /> aufgeführt. --Mps 16:39, 9. Apr. 2010 (CEST)

Nein, leider auch noch nicht live. War chronologisch an der falschen Stelle einsortiert, so dass ich es vorhin übersehen habe. Danke für den Hinweis. — Raymond ^Disk. 16:44, 9. Apr. 2010 (CEST)

Interwikis

Gibt es in keiner anderen Wikipedia eine vergleichbare Seite? --Leyo 17:41, 9. Apr. 2010 (CEST)

Die haben da keinen Raymond. Merlissimo 17:44, 9. Apr. 2010 (CEST)

Na ja, in en.wiki läuft sowas unter en:Wikipedia:Wikipedia Signpost, was aber eine Art Kurier mit etwas mehr technisches Zeug ist, und als ich da noch aktiv war, hatte die cs.source s:cs:Wikizdroje:Technické zajímavosti, was ich zu gut 80-90 Prozent von hier gefiltert habe. Ist etwas einmalig. -jkb- 18:26, 9. Apr. 2010 (CEST)

Komische Textänderung

(Sorry, nur von Admins nachvollziehbar): Wenn ich oben auf "Schützen" klicke, dann bekomme ich ja das Seite-Sperren-Formular mit den zwei Abschnitten für die Bearbeitungs- und die Verschiebesperre. Dazwischen ist ein Häckchen, das mit "Vorherige Sperroptionen aufheben" beschriftet ist. Bisher hies das an der Stelle einfach "Verschiebeschutz ändern", was es offenbar noch immer genau tut, denn nur wenn es angekreuzt ist, kann ich unten überhaupt etwas auswählen. Ist da etwas bei der Übersetzung/Aktualisierung schiefgelaufen? --PaterMcFly Diskussion ^Beiträge 22:40, 9. Apr. 2010 (CEST)

Die Übersetzung passt [2], aber es wurde einfach die komplett falsche Nachricht benutzt. Ich finde aber den Quelltext gerade nicht. Merlissimo 23:04, 9. Apr. 2010 (CEST)

Ich vermute, die Umstellung hat damit zu tun, dass jetzt auch Dateien vor dem erneuten Hochladen geschützt werden können. Beispiel. Nichtsdestotrotz halte ich den Text für sutoptimal. — Raymond ^Disk. 06:55, 10. Apr. 2010 (CEST)

Der Text müsste wohl eher "Erweiterte Sperroptionen aktivieren" oder ähnlich heissen. Jetzt liest sich das wie ein Text, der zur Entsperrung einer Seite gebraucht würde. --PaterMcFly Diskussion ^Beiträge 09:14, 10. Apr. 2010 (CEST)

Ich habe mich in translatewiki:MediaWiki:Protect-unchain-permissions/de für „Separate Sperroptionen aktivieren“ entschieden, bin da aber offen für bessere Übersetzungen. — Raymond ^Disk. 17:07, 10. Apr. 2010 (CEST)

Das ist sicher besser als das aktuelle. Danke. --PaterMcFly Diskussion ^Beiträge 19:17, 10. Apr. 2010 (CEST)

OS - zeige

Wegen einem Vandalen war meine Beo heute morgen voll von vorangestelltem "(zeige)". Da der Bearbeitungskommentar aber auch für Admins versteckt wurde ist das Wort natürlich unverlinkt. Bei der Diffansicht steht nun ebenfalls dort (zeige). Früher war das mein ein (+/-). Wenn ich das mit über die Klasse mw-revdelundel-link ausblenden möchte sind die Links wahrscheinlich auch bei nicht suppressed-versteckten Inhalte ausgeblendet, oder? (gerade kein Beispiel zum testen gefunden) Merlissimo 15:08, 10. Apr. 2010 (CEST)

Spezial:Dateiliste mit Benutzernamen

Könnte mir mal jemand auf die Sprünge helfen: Wofür braucht man das? Ist mit dem Benutzernamen der Hochlader gemeint? Warum wurde das nicht in Spezial:Benutzerbeiträge integriert? --Ska13351 17:05, 14. Apr. 2010 (CEST)

Ja, der Hochlader ist damit gemeint. In Spezial:Benutzerbeiträge wird ein Upload auch verzeichnet, aber eben bunt gemischt mit allen anderen Bearbeitungen. Beispiel, wie es nach dem nächsten Softwareupdate auch in der Wikipedia aussehen wird: translatewiki:Special:ListFiles/Raymond. Was mir noch fehlt, ist ein kleines Vorschaubild in dieser Liste. — Raymond ^Disk. 17:30, 14. Apr. 2010 (CEST)

Ist einfach eine ansprechendere Darstellung von translatewiki:Special:Log/upload/Raymond mit einem Aktualitätsfilter. Merlissimo 17:42, 14. Apr. 2010 (CEST)

Ja, viel ansprechendere Ansicht, die geradezu nach dem von Raymond angesprochenen Thumbnail schreit. Merci euch beiden. --Ska13351 21:01, 16. Apr. 2010 (CEST)

Damit die Idee nicht verloren geht, vor 2 Tagen direkt als Bug 23194: Add a thumbnail per entry of Special:ListFiles eingetragen. — Raymond ^Disk. 21:20, 16. Apr. 2010 (CEST)

Neue Tabelle iwlinks

Betrifft diese Ankündigung. Ich muss ja sagen, ich bin begeistert - mit der Tabelle kann man dann dran gehen, sie nach dem Füllen (hoffentlich geht das automatisch / per externem Script, sonst muss man alle 1 Million Artikel einmal per Nulledit aktualisieren) wieder größtenteil zu leeren (denn im ANR haben die Links nur begrenzt was zu suchen). Mal sehen, wann das live geht. --Guandalug 08:37, 16. Apr. 2010 (CEST)

Soll diese Tabelle die bestehenden Interwikilinks im Artikel ersetzen oder nur für schnellen Zugriff duplizieren? Im ersten Fall müssten die Interwikilinks aus den Artikeln entfernt werden und stattdessen ein separates Eingabefeld benötigen. Das wäre eine (erste) Auslagerung von Metadaten aus dem Artikeltext. Haben diese Daten dann eine separate Änderungshistorie? --Fomafix 09:02, 16. Apr. 2010 (CEST)

Weder-noch. Es geht hier um eine "interne" Datenbank-Hilfstabelle. Wir haben solche Hilfstabellen bereits für Weblinks, für die "Sprachlinks" und für Artikel-Links innerhalb der gleichen Sprache. Hier wird jetzt eine neue Tabelle gebaut, die Artikel-Links auf Artikel anderer Sprachen sammelt (also z.B. [[:en:Albert Einstein|Albert Einstein in der enWP]]). Diese Links sind bekanntermaßen in Artikeln unerwünscht (eine Ausnahme sind Links auf Commons). Bislang sind diese unerwünschten Links aber nicht "automatisch auffindbar" - bald (hoffentlich) schon. --Guandalug 09:11, 16. Apr. 2010 (CEST)

Ok, verstanden. Sinnvolle Erweiterung. --Fomafix 10:06, 16. Apr. 2010 (CEST)

Ich fürchte, ich habe hier ein Verständnisproblem: Seit wann sind Interwikilinks im ANR denn unerwünscht? Bisher sind sie doch in den Artikeln enthalten, ich selbst setze häufig Links zu Interwikis wie Commons, Wikiquote, Wiktionary und Wikinews. Die Verlinkung der Schwesterwikis untereinander ist doch sehr sinnvoll und wird (hoffentlich) überall auch praktiziert. Wo also könnte mein Denkfehler sein? --Stepro 11:42, 16. Apr. 2010 (CEST)

„Ste Pro (* im 20. Jahrhundert) ist ein deutscher Allgemeinspezialist, der sich vor allem auf dem Gebiet der deutschen Wikipedia hervorgetan hat.“

Solche versteckten IW-Links wie im obigen Beispiel sind unerwünscht. --32X 11:46, 16. Apr. 2010 (CEST)

WP:TF, schnelllöschen *gg* --Stepro 12:28, 16. Apr. 2010 (CEST)

(BK) Wenn ich in einem Artikel statt [[Anton Mustermann]] lieber [[:en:Anton Mustermann]] schreibe, weil der Artikel bei uns rot wäre, "drüben" aber existiert, so gaukelt das ja einen "blauen" Link vor... und führt in die falsche Sprachversion. DAS ist (in der Regel) absolut unerwünscht. Links zu den von dir genannten Schwesterprojekten sind hingegen erwünscht. Das kann man dann aus der Tabelle schon auseinanderklamüsern.... ;) Daher: Du hast schon Recht, dass die von dir gemeinten Links okay sind. Es gibt aber (genug) andere. --Guandalug 11:47, 16. Apr. 2010 (CEST)

//BK// Mit ANR ist ja wohl "im Artikeltext" gemeint. -jkb- 11:48, 16. Apr. 2010 (CEST)

Ah, verstehe, nur getarnte im Fließtext sind pöhse. Da stimme ich natürlich zu. Ich hätte nicht gedacht, dass sowas verbreitet ist. --Stepro 12:28, 16. Apr. 2010 (CEST)

Ja, echte "Interwiki"-Links sollten dann entfernt werden, aber das tolle an der Tabelle ist, dass endlich Links zu Schwesterprojekten in der DB sind. Ich habe durch Zufall schon so manchen Deadlink z.b. auf die ADB bei Wikisource gefunden, weil dort der Artikel verschoben wurde. Wohin die ADB-Vorlage aber linkt, war bisher nur durch Seitenanalyse ermittelbar, da der Link zu Wikisource nirgends in der DB auftauchte. In Zukunft lassen sich Interprojectlinks auch auf Fehler testen. Juchu :). Am Mittwoch hab ich das noch auf der Developer Conference irgendjemandem gesagt, aber nicht Brion und jetzt hat Brion das aus Berlin korrigiert... vielleicht hat sich ja mein Unmut darüber rumgesprochen *g* --APPER\^☺☹ 12:58, 16. Apr. 2010 (CEST)

Stimmt, DAS kommt dann noch dazu: Interproject - Links automatisch testbar (sowohl für eine Art "What links here" über Projektgrenzen hinweg als auch für die Gegenrichtung). In jedem Fall: Eine wichtige, LANGE erwartete Tabelle (wie Brion so richtig angemerkt hat) --Guandalug 13:21, 16. Apr. 2010 (CEST)

Die hatten wir schon auf und vor der Entwicklerkonferenz vor einem Jahr diskutiert, und es war klar, daß sie kommen soll und wird. --Purodha Blissenbach 13:42, 18. Apr. 2010 (CEST)

Spezial:Verwaltung Benutzerkonten-Zusammenführung

Wenn man in der Spalte "Methode" auf das Fragezeichen klickt, ist der Hilfetext auf Englisch. Kann man das lokal irgendwie übersetzen, oder muss da ein Serveradmin/Entwickler ran? -- Chaddy · D·B - DÜP 17:12, 9. Apr. 2010 (CEST)

Ach ja, wenn man die Tabelle sortieren könnte, wär´s ziemlich nett. ;) Aber das kann wohl wirklich nur ein Entwickler ändern. -- Chaddy · D·B - DÜP 17:13, 9. Apr. 2010 (CEST)

sulutil:Chaddy kann man sortieren. Aber welchen Text meinst du. Die ganzen Tooltips sind bei mir lokalisiert. Merlissimo 17:18, 9. Apr. 2010 (CEST)

(BK) Englischer Hilfetext: Bei mir ist die Fragenzeichen-Hilfe auf Deutsch, dafür ist im Block darüber die 4. Zeile noch mit "Total editcount" beschriftet. Übersetzt sind die ganzen Texte aber definitiv. Ich vermute, dass der Lokalisierungscache nur zum Teil aktualisiert wurde. Dieser wird aber auf jeden Fall heute Nacht (genau genommen jede Nacht) aufgefrischt. Daher warte ich noch bis morgen bis einer tiefergehenden Fehlersuche.

Sortierbarkeit: Fiel mir heute morgen auch als erstes ein. Nicht schwierig, aber tricky, da das Datum unsichtbar in einer sortierbaren Form gebracht werden muss. — Raymond ^Disk. 17:22, 9. Apr. 2010 (CEST)

Und der Kasten selbst heißt "Global user info" Merlissimo 17:27, 9. Apr. 2010 (CEST)

Die nicht übersetzten Nachrichten sind Mediawiki:centralauth-admin-info-editcount und Mediawiki:centralauth-admin-info-header. Wird von System vielleicht nicht erfasst, weil durch wfMsgHtml( "centralauth-admin-info-$tag" ) erzeugt. Merlissimo 17:39, 9. Apr. 2010 (CEST)

Nein, daran kann es nicht liegen. Solche Konstrukte haben wir (leider) mehrfach. Und übersetzt sind sie auch: translatewiki:MediaWiki:Centralauth-admin-info-header/de bzw. translatewiki:MediaWiki:Centralauth-admin-info-editcount/de. Aber erst im März, der Branchpoint, der dem heutigen Update zu Grunde liegt, lag aber im Februar. Damit sollten die Übersetzungen aber heute Nacht mit der Auffrischung des Lokalisierungscaches ab morgen zu sehen sein. — Raymond ^Disk. 17:50, 9. Apr. 2010 (CEST)

Ok, warten wir mal bis morgen.

Ich finde es gut, dass sich endlich mal wieder was getan hat, das letzte größere Update lag ja schon länger zurück. Nur nervig finde ich, dass bei den eigenen Beiträgen die Buttons (Unterschied | Versionen) vertauscht wurden. Aus beinahe 5-jähriger Gewohnheit klicke ich da jetzt immer auf den falschen Button... -- Chaddy · D·B - DÜP 18:08, 9. Apr. 2010 (CEST)

Spätestens morgen hast du dich daran gewöhnt. Jetzt ist die Anzeige von (Unterschied | Versionen) aber konsistent in allen Listen, das halte ich für wichtiger als ein paar Fehlklicks bis man sich dran gewöhnt hat. — Raymond ^Disk. 18:23, 9. Apr. 2010 (CEST)

<lamentier>Wär' natürlich praktisch, wenn man, wie im Sulutil, auch noch die Rechte aufgelistet bekäme. </lamentier>--PaterMcFly Diskussion ^Beiträge 22:44, 9. Apr. 2010 (CEST)

Update zur Sprache: Heute ist bei mir alles auf Deutsch zu sehen. Könnt ihr das bestätigen? — Raymond ^Disk. 07:20, 10. Apr. 2010 (CEST)

Ja, kann ich bestätigen. Allerdings fällt mir auf, dass der Browser (IE8) diverse Skriptfehler in centralauth.js anmeckert (allerdings ohne sichtbare Konsequenzen) . --PaterMcFly Diskussion ^Beiträge 09:17, 10. Apr. 2010 (CEST)

Nach einem Reload der Seite funktioniert es. Wozu auch immer das JavaScript gebraucht wird. Scheint so das die Variable wgCursorPosition nicht richtig initalisiert wird. Der Umherirrende 10:48, 10. Apr. 2010 (CEST)

Bug 23279 --Der Umherirrende 21:28, 21. Apr. 2010 (CEST)

Bei allen Zahlen fehlt die Formatierung und Zahlen in Tabellen sollte man rechtsbündig schreiben. Der Umherirrende 10:48, 10. Apr. 2010 (CEST)

Per rev:64872 erledigt. — Raymond ^Disk. 14:18, 10. Apr. 2010 (CEST)

Danke --Der Umherirrende 21:16, 10. Apr. 2010 (CEST)

Da Benutzerkonten, also wahrscheinlich auch globale, immer mit einem Großbuchstaben beginnen, sollte der erste Buchstabe des Benutzernamens automatisch groß geschrieben werden (vgl. [3]). --Steef ³⁸⁹ 20:39, 10. Apr. 2010 (CEST)

Hier scheint die Normalisierung der Benutzernamen nicht zu funktionieren, sollte aber auf jedem Fall, da es andere Spezialseiten genauso handhaben. Der Umherirrende 21:16, 10. Apr. 2010 (CEST)

Ich erhalte bei Steefs Link ein „Es gibt kein globales Benutzerkonto „steef389“.“ Meint ihr, dass man stillschweigend Uppercase setzen sollte? — Raymond ^Disk. 23:09, 10. Apr. 2010 (CEST)

Es gibt ja sehr alte lokale Benutzerkonten, die nicht Uppercase sind. Diese können aber heute doch nicht mehr genutzt werden, oder? Zumindest gibt es einige Benutzer, die es sowohl mit klein als auch mit Großbuchstaben existieren, aber nur der First-Letter-Uppercase aktiv ist. Falls das stimmt kann es keine klein geschriebenen globalen Konten geben. Merlissimo 23:14, 10. Apr. 2010 (CEST)

Es gibt 35 Accounts mit einem Kleinbuchstaben, die aber alle versteckt und somit nicht über diese Seite abfragbar sind (ich kann deswegen auch nicht sehen, ob die gelocked sind). Da die Accounts harmlose Namen wie "garden" haben, war das wohl ein technischer Grund. Also kann man das mit dem Großbuchstaben wohl machen. Merlissimo 23:28, 10. Apr. 2010 (CEST)

Die Klasse User von MediaWiki hat eine Methoden, die einem den Benutzernamen normalisiert (getCanonicalName), vielleicht sollte man ähnliche auch für den CentralAuthUser implementieren. Es gibt ja noch andere Spezialseiten, wo man einen Benutzernamen eintragen kann. Die einfache Variante ist natürlich einfach den ersten Buchstaben groß zu machen. Der Umherirrende 16:47, 11. Apr. 2010 (CEST)

Von Steef389 als Bug 23213 gemeldet. Der Umherirrende 12:35, 18. Apr. 2010 (CEST)

Mal noch ne Frage dazu: [4]. Was sagt mir das Symbol, das mit "keine Benutzerbeiträge" unterlegt ist? --APPER\^☺☹ 18:07, 11. Apr. 2010 (CEST)

Das besagt, dass zum Zeitpunkt des Mergens der lokale Account keine Benutzerbeiträge hatte und damit automatisch usurpiert wurde (oder durch Stewards damals? Hab's vergessen). — Raymond ^Disk. 18:49, 11. Apr. 2010 (CEST)

auf den ersten Blick hat die Spezialseiten keine wirklichen footer (Nur für stewards um Accounts trennen zu können). Also entweder einen einbauen, dann können wir hier eine Legende daraus erstellen oder direkt für alle eine Legende im Quelltext bauen, oder? Merlissimo 19:43, 11. Apr. 2010 (CEST)

Du solltest einen Bug aufmachen, da Raymond anscheind derzeit nicht so viel Zeit hat, um die Ideen direkt umzusetzen. Ich bin mir nicht sicher, ob es wirklich einer Legende bedarf. Überflüssig wird sie aber auf keinen Fall sein. Der Umherirrende 21:28, 21. Apr. 2010 (CEST)

Ja bitte, Bug aufmachen, da ich a) wenig Zeit (aber die habe ich immer) und b) die Extension nicht installiert habe und alle Patches freihändig sind. — Raymond ^Disk. 21:47, 21. Apr. 2010 (CEST)

Update: Tabelle mit rev:64956 sortierbar gemacht. — Raymond ^Disk. 13:03, 12. Apr. 2010 (CEST)

Das, was die Seite noch von sulutil unterschiedet ist die Angabe der Benutzerrechte. Wenn man nicht gerade Vandalen global jagt, ist das für mich der Hauptgrund sulutil zu benutzen (gerade als Botbeteiber). Wäre es ist nicht sinnvoll dies dort zu ergänzen (inkl. Globaler Gruppen). Dann könnte man damit auch sulutil im Contrib-Footer ersetzen. Merlissimo 21:45, 20. Apr. 2010 (CEST)

Dürfte Bug 18917 sein. Der Umherirrende 21:28, 21. Apr. 2010 (CEST)

rev:64956 fixed Bug 18918. Der Umherirrende 21:28, 21. Apr. 2010 (CEST)

safesubst

Hallo, funktioniert das neue Schlüsselwort "safesubst" nun eigentlich oder nicht? Ich würde es gern in Verbindung mit Vorlage:Literatur einsetzen, aber derzeit wird nichts anderes ausgegeben als bei "subst". Oder muss in der Vorlage was geändert werden? Wenn ja, was genau? Grüße --Cepheiden 09:57, 3. Mai 2010 (CEST)

Mir war die Verwendung des Schlüsselwortes erst auch nicht klar. Ich habe es aber dann an der Vorlage:Vorschau ausprobiert und somit die Funktionsweise erkannt. Das Schlüsselwort kann innerhalb der Vorlagenprogrammierung verwendet werden, im Falle einer Einbindung verhält es sich so, als sei es nicht da (Also wird eine Einbindung vorgenommen und nicht die Unaufgelöste Vorlagen angezeigt), bei einem subst, verhält es sich so, als ob es da wäre. Somit wird die Vorlage:Vorschau auf der Seite Wikipedia:Textbausteine/Benutzerseiten richtig angezeigt und gleichzeitig kann sie gesubst werden. Für eine Dokumentation war ich mir aber noch zu schade.

Das Schlüsselwort heißt nicht, das bei der direkten Verwendung alle Untervorlagen/Parser Function innerhalb der Vorlage aufgelöst werden. Man könnte höchstens jede Untervorlage/Parser Function mit safesubst versehen, dann würde es funktionieren, aber es macht den Quelltext nicht schöner. Ich hoffe, das war verständlich. Der Umherirrende 16:41, 3. Mai 2010 (CEST)

Spezial:RevisionDelete, ein komfortables Versionslöschungs-Interface, ist jetzt auch für Administratoren aktiviert.

Bitte jubeln sie JETZT! ;) --Guandalug 16:23, 18. Mai 2010 (CEST)

Das haben wir doch bestimmt schon alle um 15:50:56 Uhr gemacht,oder? Merlissimo 16:26, 18. Mai 2010 (CEST)

Kann man auch länger machen. (Ich habs grade erst mitbekommen...) --Guandalug 16:27, 18. Mai 2010 (CEST)

--Capaci34 Ma sì! 16:28, 18. Mai 2010 (CEST)

Jetzt wäre wohl der Zeitpunkt Hilfe:Versionslöschung und Hilfe:Oversight (Achtung, nicht dasselbe wie Wikipedia:Oversight!) zu aktualisieren und einmal die Verwirrung um die Benamsung aufzulösen. Gibt es für das Feature eigentlich schon einen besseren deutschen Namen? Ach ja: *freu*. --PaterMcFly Diskussion ^Beiträge 17:47, 19. Mai 2010 (CEST)

@PaterMcFly: strategy:Proposal:Change usergroup name "Oversight" – diese ganze Namensgebung ist ziemlich willkürlich und verwirrend. @sysops: Glückwunsch :) --Church of emacs D B 18:18, 19. Mai 2010 (CEST)

Ich hab mal Hilfe:Versionslöschung aktualisiert und Hilfe:Oversight dorthin redirected. Zuviel Seiten zum Gleichen braucht's ja nicht. --PaterMcFly Diskussion ^Beiträge 17:41, 20. Mai 2010 (CEST)

Dann sollte dort aber klarer der Unterschied zwischen deleterevision und hiderevision-Recht herausgestellt werden. Merlissimo 17:44, 20. Mai 2010 (CEST)

Da ist einiges noch verbesserungsfähig, das steht ausser Zweifel. Auch sollte zum Beispiel die Seite Wikipedia:Versionslöschungen/Hinweise am besten gelöscht werden oder zumindest die Inhalte mit Hilfe:Versionslöschung zusammengefasst werden. Da gibt es deutlich zuviele Redundanzen bei den Hilfstexten. --PaterMcFly Diskussion ^Beiträge 08:49, 21. Mai 2010 (CEST)

Ich war mal so frei. Grüße -- Nolispanmo Disk. Hilfe? 16:54, 21. Mai 2010 (CEST)

jQuery

Sind Änderungen an MediaWiki, die in irgendeiner Form mit jQuery zu tun haben, interessant genug, auf der Vorderseite aufgeführt zu werden? Anlass ist Bug 23580. Add two new jquery events, LivePreviewPrepare and LivePreviewDone. Scripts like Navigation Popups can use this to bind to these events so they can setup their code to work with the previews.

Falls ja, würde ich einen separaten Unterabschnitt jQuery hinter dem API-Block aufmachen. — Raymond ^Disk. 16:56, 21. Mai 2010 (CEST)

Wenn du es so formulieren könntest, dass auch Admins ohne Informatikstudium kapieren, worum es überhaupt geht... ;-) Stefan64 16:59, 21. Mai 2010 (CEST)

Ganz ehrlich Stefan, ich denke mit diesen Meldungen können überhaupt nur Programmierer was anfangen. Deswegen werde ich die 1:1 in Englisch, wie die API-Meldungen auch, nach vorne nehmen. Es ist denn die Aufgabe der Script-Bastler, ihre Ergebnisse Otto-Normal-User-freundlich bekannt zugeben.— Raymond ^Disk. 17:14, 21. Mai 2010 (CEST)

jQuery ist sicherlich ganz interessant, allerdings nur für einen sehr eingeschränkten Kreis. Mich würd's freuen … Grüße, —DerHexer (Disk., Bew.) 17:01, 21. Mai 2010 (CEST)

Ich fände es auch interessant.

@Stefan: Jeder Programmierer wird sich immer direkt den Quelltext der für ihn interessanten Änderungen anschauen um es genau zu verstehen, da "ungefähr verstehen" hier nicht hilft und die Funktionen klein und überschaubar sind. Merlissimo 17:35, 21. Mai 2010 (CEST)

+1 --Steef ³⁸⁹ 18:28, 22. Mai 2010 (CEST)

„filemover“-Benutzerrecht

Sehr gut, dass das endlich mal für alle verfügbar ist. Aber wie lange müssen wir hier noch warten, bis alle dürfen? -- Chaddy · D·B - DÜP 00:51, 21. Mai 2010 (CEST)

Ich hoffe, es wird nicht soweit kommen, dass alle (= Automatisch bestätigte Benutzer) Dateien verschieben können. Da wären Movewars vorprogrammiert…

Wenn eine commonsfähige Datei falsch/unpassend benannt ist, so verschiebt man diese am besten (unter einem passenden Namen) nach Commons. --Leyo 01:41, 21. Mai 2010 (CEST)

Naja, viel schlimmer als bei Artikeln wird das auch nicht werden... -- Chaddy · D·B - DÜP 01:43, 21. Mai 2010 (CEST)

Wenn ich sehe, wie wenig Vorlage:Datei umbenennen verwendet wird, ist das hier wohl kein echtes Bedürfnis. --Leyo 01:45, 21. Mai 2010 (CEST)

Im Gegensatz zu Commons habe ich lokal auch noch selten wirklich blöde Dateinamen gesehen. Ausserdem haben wir, im Gegensatz zu Commons quasi die dritte Berechtigungsstufe. Man könnte also das Recht auch nur den Sichtern geben. --PaterMcFly Diskussion ^Beiträge 08:57, 21. Mai 2010 (CEST)

Allen Sichtern dieses Recht zu geben, wäre IMHO keine gute Idee.

Wenig blöde Dateinamen? Dann schau mal hier und hier… --Leyo 14:28, 21. Mai 2010 (CEST)

Warum? Ursprünglich sollten alle dieses Recht bekommen. Dann hieß es, für eine Übergangsphase bekommen es nur Admins... Viel mehr Unsinn als beim Artikelverschieben kann man damit auch nicht anstellen... -- Chaddy · D·B - DÜP 16:04, 21. Mai 2010 (CEST)

Im Unterschied zu Artikeln gibt es bei Namen von Dateien nie nur „ein richtig“. Rein kosmetische Umbenennungen sind nicht sinnvoll, würden durch unerfahrene Sichter aber bestimmt gemacht. --Leyo 16:49, 21. Mai 2010 (CEST)

Yuk, sehr aussagekräftige Namen... Kann man sowas nicht per globalen Filter verbieten? Oder würde es dazu führen, dass die Benutzer gar nichts mehr hochladen, weil sie unverständliche Fehler bekommen? --PaterMcFly Diskussion ^Beiträge 22:51, 21. Mai 2010 (CEST)

Lässt sich prinzipiell über die MediaWiki:Titleblacklist ausblenden, siehe Commons oder en.wikipedia. --The Evil IP address 17:23, 25. Mai 2010 (CEST)

Dafür gibt es auch noch MediaWiki:Filename-prefix-blacklist, die oben verlinkten werden Altfälle sein, oder das Hochladen mit ignorieren der Warnung (glaube das funktioniert dann). Mit der titleblacklist hat man aber mehr Möglichkeiten, zum Beispiel das Anzeigen einer Nachricht Der Umherirrende 19:21, 25. Mai 2010 (CEST)

Kategoriebaum

Wenn ich mich nicht irre, gab´s dafür mal ein Tool auf dem Toolserver. Gibt´s das immer noch? Jetzt würde es wieder gebraucht werden... -- Chaddy · D·B - DÜP 16:59, 27. Mai 2010 (CEST)

tools:~daniel/WikiSense/CategoryTree.php Merlissimo 17:05, 27. Mai 2010 (CEST)

Leider ersetzt das nicht die „Inhaltsangabe“, also „(x Dateien)“, vgl. hier. --ireas Diskussion // Bewertung 17:09, 27. Mai 2010 (CEST)

Naja, aber mal besser als gar nix. Danke für den Link, Merlissimo. -- Chaddy · D·B - DÜP 17:22, 27. Mai 2010 (CEST)

CSS/JS-Vorschau

Moin, im Vorgriff auf eine potentielle Meldung bin ich gerade am Bug 23733 am arbeiten. Dabei ist mir der Satz „Tipp: Benutze den Vorschau-Button, um dein neues CSS vor dem Speichern zu testen.“ aufgefallen, den es schon ewig gibt, wann man seine eigene Monobook.css/.js etc. bearbeitet.

Nur ehrlich, ich habe noch nie verstanden, wie das funktionieren soll. Bzw. funktioniert es überhaupt? — Raymond ^Disk. 08:39, 2. Jun. 2010 (CEST)

Bei vector und CSS funktionierts, hab ich gerade vor dem speichern dieser Änderung getestet. Lustigerweise war nach dem speichern die Überschrift wieder normal, so dass ich erstmal den Browsercache leeren musste ;-). Ich seh keinen Grund, warum das bei Monobook nicht auch klappen sollte. --Gnu1742 08:43, 2. Jun. 2010 (CEST) P.S.: Den Einwand von Happy-Melon bei dem Bug kann ich sehr gut nachvollziehen.

Danke, klappt bei mir jetzt auch. Dann war ich bisher einfach zu doof :-( — Raymond ^Disk. 08:50, 2. Jun. 2010 (CEST)

Quatsch, du hattest ganz bestimmt einfach zu wenig Kaffee. *Kaffee servier* *Keks dazutu* -- Gnu1742 08:53, 2. Jun. 2010 (CEST)

Danke, den hat es wirklich gebraucht. Ich sage auch nicht, wo mein Fehler lag. Das ist zu peinlich *rotwerd* — Raymond ^Disk. 09:25, 2. Jun. 2010 (CEST)

In einem anderen Bug hatte ich mal IDs vorgeschlagen und es kamen Klassen. Da scheint noch eine einheitliche Regelung zu fehlen. Die Vorschau funktioniert immer wunderbar und vor einiger Zeit gab es auch mal einen fix, das sie in allen Skins funktioniert. Die Vorschau funktioniert auch auf Seiten, die nicht nach einem Skin benannt wurden. Der Umherirrende 18:35, 2. Jun. 2010 (CEST)

Suchvorschläge-Bug

Wenn ich "Kategorie:Vorlage:D" in die Suche eintippe um z.B "Kategorie:Vorlage:Datenbanklink" finden zu wollen, kommen nach dem Tippen des "D" Vorschlage aus den Vorlagennamensraum anstatt von Kategorien. Das war vor ein paar Tagen mit Sicherheit noch nicht (Ich benutze das ständig, weil viele, die meinen Bot verwenden die Kategorie "Kategorie:Vorlage:Navigationsleiste ..." vergessen anzugeben und ich so danach suche) Ich finde allerdings keine Softwareänderung, die zum Bug passt. Jemand eine Idee wo das geändert wurde? Wenn ich das nur so allgemein als Bug melde, ist das in einem halben Jahr nicht gefixt und ich vermisse es jetzt schon. Merlissimo 04:03, 3. Jun. 2010 (CEST)

Mir was das auch mal aufgefallen: Bug 22773. Meinst du, das war zwischenzeitlich wieder "richtig". Wenn es zwischenzeitlich mal richtig war, müsste man schauen, ob sich an der SearchEngine etwas geändert hat, nur weiß ich nicht, wo man die Änderungen findet. Der Umherirrende 17:06, 3. Jun. 2010 (CEST)

Die Devs meinten die Beta-Suche wäre nun allgemein verfügbar. Ich habe kein Beta aktiviert. Du? Merlissimo 02:21, 4. Jun. 2010 (CEST)

Bei mir bringt er auch nur Vorlagen-Vorschläge, sowohl bei "normal", als auch bei "Beta". -- Chaddy · D·B - DÜP 02:54, 4. Jun. 2010 (CEST)

Ich nutze kein Beta. Fühlt euch aber frei, den Bug zu kommentieren, die Überschrift oder Komponente zu korrigieren, falls ihr Ideen habt, dafür ist er da. Der Umherirrende 17:35, 4. Jun. 2010 (CEST)

Umstellung auf neuen Skin

Kann mal jemand den Cache flushen? Für einen unangemeldeten Nutzer ist es schlicht nervend, wenn eine Seite im Vektor-Skin und die nächste im Monobook-Skin ausgeliefert wird. Der alte Trick klappt leider nicht mehr. --32X 10:13, 10. Jun. 2010 (CEST)

Das könnte schwer werden. --Guandalug 10:16, 10. Jun. 2010 (CEST)

Ist aber in Arbeit: # 08:32 mark: Florida squid purge done, esams cache dump done. Started purging esams pages. — Raymond ^Disk. 10:59, 10. Jun. 2010 (CEST)

Obwohl ich wieder auf Monobook zurückgestellt habe, fehlen mir die Extra-Editbuttons. Statt dessen habe ich die Vector-Bearbeitungshilfe. --Leyo 10:20, 10. Jun. 2010 (CEST)

Gut, dass ich die nicht nutze. Allerdings: Hast du "nur" zurückgestellt? In den Einstellungen aktivieren sich auch die Beta - Funktionen, die müsstest du im Reiter "Bearbeiten" auch ausschalten. --Guandalug 10:32, 10. Jun. 2010 (CEST)

Daran lag's, danke. --Leyo 10:37, 10. Jun. 2010 (CEST)

Bei mir dann aber auch erst nach "strg+r". Nunja, danke für den Hinweis. --Cepheiden 11:22, 10. Jun. 2010 (CEST)

Nur zum Verständnis, wann kann man damit rechnen, dass der Monobook-Skin implementiert wird? Hofres 14:11, 10. Jun. 2010 (CEST)

Der Monobook-Skin IST doch implementiert? Du meinst wohl, wann PDD seine Monobook.js auf Vector.js umgestellt hat? Frag ihn... :D --Guandalug 14:15, 10. Jun. 2010 (CEST)

" ... Frag ihn ... " - etwas ähnliches habe ich hier gemeint: Wikipedia:Fragen zur Wikipedia#Klappbare Navileisten. -jkb- 14:26, 10. Jun. 2010 (CEST)

@ Guandalug: Äh ja ;) @jkb: In der Tat wäre eine kurze Einführung der technisch Versierten bei solchen elementaren Änderungen hilfreich. Hofres 14:36, 10. Jun. 2010 (CEST)

Vorschau-Text

Editiert man etwas und klickt dann auf Vorschau, so wird zwar eine Mitteilung angezeigt wie früher, jedoch ist sie so formatiert, dass sie wie eine Sektion aussieht. Irgendeine farbige unterscheidung wie vorher wäre wohl besser. Gruß -jkb- 11:17, 10. Jun. 2010 (CEST)

Sowas bitte nach Wikipedia:Usability-Initiative/Feedback. Das ist Vector spezifisch. Merlissimo 14:47, 10. Jun. 2010 (CEST)

Aha. Ist gleich da. Danke -jkb- 15:28, 10. Jun. 2010 (CEST)

Anzeige nur der wichtigsten Interwikis

Ich hoffe, dass dieses „Feature“ niemals live geht... -- Chaddy · D·B - DÜP 01:55, 8. Jun. 2010 (CEST)

+1! Gruß,--Tilla 2501 01:56, 8. Jun. 2010 (CEST)

Wieso nicht? Ich sehe keinerlei Nachteile. --Revo Echo der Stille 02:11, 8. Jun. 2010 (CEST)

Vernachlässigung/Abwertung der "unwichtigen" Sprachversionen z. B.? -- Chaddy · D·B - DÜP 03:49, 8. Jun. 2010 (CEST)

Plattdeutsch kennt mein Browser nicht ... --Norbirt 06:05, 8. Jun. 2010 (CEST)

• Schließe mich Chaddy an. Wer definiert, welche Sprachversionen "wichtig" oder "unwichtig" sind? --Mogelzahn 17:16, 8. Jun. 2010 (CEST)

Das ist ja gerade das Raffinierte: Jeder Benutzer, der seinem Browser beibringt, welche Sprachen er mag. - Abgesehen von Norbirts - berechtigtem - Einwand sieht es in der Theorie damit vollkommen korrekt aus. Nur wer hat schon die entsprechenden Sprachen in seinem Browser eingestellt? Praktisch ist es in meinen Augen völlig daneben. - Sinnvoll fände ich allenfalls die bevorzugte Darstellung der entsprechenden Sprachen (also an den Anfang damit, ich suche mir im Klassik-Skin manchmal einen Wolf, bis ich den englischen WP-Link finde). --Ska13351 20:56, 8. Jun. 2010 (CEST)

Wenn es, wie diese vermaledeiten selbsteinklappenden Seitenmenüs, abschaltbar ist... von mir aus. Mögen muss ich das ja nun nicht (das erinnert mich zu sehr an das MS-Office-feature mit den dynamischen Menüs. Noch so ein "schnell aus damit" - Krempel) --Guandalug 17:20, 8. Jun. 2010 (CEST)

Eigentlich bräuchte ich nur Englisch. Die anderen könnten defaultmässig alle zugeklappt sein. Wenn ich so nachdenke, wie man den Platz links generell besser nützen könnte. Es könnten ja die letzten 10 von mir aufgerufenen Begriffe gespeichert werden, oder für benutzerdefinierte Bookmarks genützt werden...--FrancescoA 17:38, 8. Jun. 2010 (CEST)

Gutes und wünschenswertes Feature. Wer nach Beiträgen in irgendwelchen exotischen Sprachen sucht, wird es gewohnt sein, dass er etwas tiefer suchen muss, als nach Englisch oder Französisch. Ergo würden es defaultmäßig die 8 oder 10 weitverbreitetsten Sprachen tun, alle anderen könnten in einem Ausklappmenü unterkommen. -- · peter schmelzle · d · @ · 17:57, 8. Jun. 2010 (CEST)

strikt dagegen, schaue öfter mal bei allen angegebenen wikis vorbei, z.B. wegen (lokaler) Bildersuche, jedesmal erst doppelklick und so? warum dann nicht gleich alle incl EN verstecken <ironie>wir deutschsprachigen sind doch sowieso die größten...</ironie> NobbiP 19:28, 8. Jun. 2010 (CEST)

Ich hoffe, es lässt sich irgendwie per Benutzer-CSS abschalten, so dass man immer alle Interwikis sieht... Warum wird solcher Mist eigentlich nicht als freiwilliges Gadget gebastelt? Btw., so wirklich barrierefrei ist das dann aber auch nicht mit so einem Ausklappböxchen, oder? --തോഗോ^{D ♇} 19:36, 8. Jun. 2010 (CEST)

Die Ausklappbox gibt es nur im Vektor-Skin und kann mit der Option "Zusammenklappbares Navigationsmenü links aktivieren" in den Einstellungen deaktiviert werden. Die anderen Bereiche in der Navigation werden dann aber auch nicht mehr geklappt. Der Umherirrende 19:48, 8. Jun. 2010 (CEST)

Wenn, dann sollte es default deaktiviert sein und für die, die es möchten aktiviert werden. Der Leser sollte auf jeden Fall immer alle Interwikis zu sehen bekommen. -- Chaddy · D·B - DÜP 21:37, 8. Jun. 2010 (CEST)

Warum? Ich glaube ein Grund bei der Entwicklung des neuen Skins war, die sichtbaren Links zu reduzieren. Gerade nur Leser sind mit der Flut der vielen Links einfach überfordert. Man sollte nicht immer vom langjährigen WP-Autor auf den Nur-Leser schließen.

Es wird niemals mehr ein Skin geben, das für Power-Autoren wie unsereiner und Nur-Leser gleichermassen geeignet ist. Die PDD-Monobook.js zeigt ja schon den Weg. liesel 08:26, 10. Jun. 2010 (CEST)

@Ska13... Wenn du den englischen Interwiki immer oben haben willst, füge folgendes in deine Monobook.js ein:

 var moveInterwikisToTopArray = ["en"];
 document.write('<script type="text/javascript" src="http://de.wikipedia.org/w/index.php?title=' +
 'Benutzer:TMg/moveInterwikisToTop.js&action=raw&ctype=text/javascript"><\/script>');

--Marcel1984 ^{(?! | ±)} 21:22, 8. Jun. 2010 (CEST)

Das' ja nun extrem hübsch - Vielen Dank! --Ska13351 22:32, 8. Jun. 2010 (CEST)

Das Argument mit der Barrierefreiheit zeiht nicht wirklich. Wenn ich z.B. den Artikel Deutschland anschaue, dann empfinde ich es inzwischen schon als Barriere, dass ich erst etwa anderhalb Bldschirmseiten interwikis runterrollen muss, bevor ich zur englischen Version des Artikels komme. Keine Ahnung, welche bizarren Minderheiten die dort sonst noch so gelisteten exotischen Sprachen sprechen, aber bei aller Barrierefreiheit für Minderheiten sollte man die Barrierefreiheit für Normal-User nicht aus dem Auge verlieren. Daher wäre eine Beschränkung auf die gebräuchlichsten Sprachen wirklich sinnvoll. alternativ wäre auch ein Skript wünschenswert, dass primär diejenigen Interwikis ausgibt, in denen die längsten Artikel vorhanden sind, damit wenigstens mal diejenigen ausgefiltert werden, die nur irgendwelche automatisch erzeugten Substubs zum Thema bieten.-- · peter schmelzle · d · @ · 21:58, 8. Jun. 2010 (CEST)

Marcel1984 hat unmittelbar über Deinem Beitrag ein Skript mit genau diesen Anforderungen vorgestellt. (Zumindest den ersten. Die Analyse nach Länge der andersprachigen Artikel würde einen Rückgriff auf diese bedeuten - und das macht bei Deinem Beispiel schlicht und ergreifend keinen Spass oder würde vermutlich die Hamster in den Streik treiben.) --Ska13351 22:32, 8. Jun. 2010 (CEST)

Ach ja, man kann auch mehrere Sprachversionen mit Komma getrennt aufführen, z.B. ["en", "fr"] --Marcel1984 ^{(?! | ±)} 22:41, 8. Jun. 2010 (CEST)

Oh ja, mit der Komma-Erweiterung auf mehrere nach oben verschobene Interwikis wirds richtig gut, besten Dank! -- · peter schmelzle · d · @ · 23:57, 8. Jun. 2010 (CEST)

• Vielleicht sollten die Entwickler ab und zu einen Blick auf WP:Neutraler Standpunkt (en:WP:NPOV) werfen. Dann würden sie erkennen, daß man nicht jeden schwachsinnigen Featurerequest umsetzen muß. Mit welcher Begründung werden die "fünf wichtigsten" Sprachversionen bevorzugt? Und was sind die fünf wichtigsten Sprachversionen: EN, DE, FR, ES, PL nach der Artikelzahl oder vielleicht doch ZH, EN, AR, ES, PT nach der Zahl der Sprecher. Ich freue mich dann schon mal, wenn Schmelzle und Revo mal auf EN einen Backlink nach DE suchen, der dank dieses so fortschrittlichen Features nicht mehr direkt angezeigt wird. --Matthiasb (CallMeCenter) 08:17, 10. Jun. 2010 (CEST)

PS: Das Argument Barrierefreiheit ist kein Argument, sondern eine gesetzlich Verpflichtung. --Matthiasb (CallMeCenter) 08:27, 10. Jun. 2010 (CEST)

Na dann können die blinden Zazaki- oder Bikol Central-Sprecher (was sind das überhaupt für Sprachen) ja dankbar sein, dass ihre Exotendialekte noch vor Sprachen einsortiert sind, die wesentlich mehr Menschen sprechen. Wenn die Barrierefreiheit dazu führt, den nichtbehinderten Lesern Barrieren aufzubauen, ist es keine wirkliche Barrierefreiheit.-- · peter schmelzle · d · @ · 10:20, 10. Jun. 2010 (CEST)

Ja schlimm, nicht wahr. Bikolano ist eine Sprache, die zehnmal häufiger Gesprochen wird, wie Lëtzebuergesch. Also weg mit Lëtzebuergesch aus der Sprachleiste, ist völlig unwichtig. Willkommen im Kulturimperialismus. --Matthiasb (CallMeCenter) 11:03, 10. Jun. 2010 (CEST)

@Umherirrender: Ich habe das Häkchen in EN gesetzt, daß nicht geklappt wird. Die Software klappt manchmal aber doch. Ist vermutlich ein Bug. Ziemlich nervig. --Matthiasb (CallMeCenter) 08:28, 10. Jun. 2010 (CEST)

„Das Argument Barrierefreiheit ist kein Argument, sondern eine gesetzlich Verpflichtung“: In einem Wort: Bullshit.

Da zudem die Funktionsweise des Interwiki-Features hier einigen nicht klar zu sein scheint, hier mal der Versuch einer Erklärung von Art und Weise und Sinn und Zweck. Zunächst aber: Auch ich hoffe auf eine Deaktivierbarkeit, da ich sehr viel durch die Interwikis zu allen möglichen Sprachen hin und herspringe. Aber aus technischer und Nur-Leser-Sicht eine durchaus vernünftige Idee: Angezeigt werden auf jeden Fall die Interwikis, von denen bekannt ist, dass der jeweilige Leser sie spricht, und so priorisiert, wie der Leser das auch seinem Browser vorgegeben hat. Danach wird die Liste mit weiteren Interwikis aufgefüllt, die Auswahl dazu geschieht nach Größe der jeweiligen Wikipedia (damit grob einhergehend: Gewisse Artikelqualität wegen aktiver Community, gewisse Relation zur Sprecher- und, wichtiger, vor allem Wikipedia-Nutzerzahl, gewisse Konsistenz, weil die fünf Interwikis im Wesentlichen immer diesselben sind, ...). Damit sind die wichtigsten Sprachen stets auf einen Blick erschlagen, Normalbenutzer bekommen nicht lange Listen mit Links mit denen sie sowieso nichts anfangen können, und auch Sprecher von exotischen Sprachen müssen ihre Sprachversion in der Interwiki-Linkliste von en.wp nicht mehr unter den 87 Einträgen heraussuchen. Wer doch an Sprache X interessiert ist, findet sie ohne große Suche nur einen Klick entfernt. --YMS 10:44, 10. Jun. 2010 (CEST)

Es ist beim Navigieren einfacher ein wenig zu scrollen, als zu klicken. Das mußt du nämlich bei einem Artikel, der länger ist als eine Bildschirmseite sowieso. --Matthiasb (CallMeCenter) 10:49, 10. Jun. 2010 (CEST)

PS: Was du als Bullshit abtust, nennt sich Behindertengleichstellungsgesetz (Deutschland) --Matthiasb (CallMeCenter) 10:52, 10. Jun. 2010 (CEST)

Wie gesagt, die halb weggeklappten Interwikis würde ich auch nicht wollen. Ich kenn aber auch die Sprachenliste der Wikipedia, und bin, anders als vermutlich 99,99% der Wikipedia-Benutzer (= Leser) keineswegs nur an den paar Sprachen interessiert, die ich spreche.

Das BGG (du meinst § 11) gilt für „Dienststellen und sonstigen Einrichtungen der [deutschen] Bundesverwaltung, einschließlich der bundesunmittelbaren Körperschaften, Anstalten und Stiftungen des öffentlichen Rechts“ - eine solche ist die Wikimedia Foundation meines Wissens nicht. (Außerdem handelt es sich ohnehin eher um eine gesetzliche festgehaltene Absichtserklärung, vgl. Stichworte wie „schrittweise“ oder „wirkt darauf hin“). --YMS 11:04, 10. Jun. 2010 (CEST)

Und wenn es nur um die reine Barrierefreiheit geht, kann man die auch durch eine speziell darauf ausgelegte Spezialseite erreichen, dazu braucht man keine zig Interwiki-Exoten auf jeder lemmakräftigen Seite mitschleppen.-- · peter schmelzle · d · @ · 11:14, 10. Jun. 2010 (CEST)

Könnte gut sein, daß für die 200 Millionen Menschen (auf ein paar Mega nach oben oder untern kommt es nicht an), die Bengali sprechen, Deutsch auch für etwas exotisches halten. Kann dann bei denen auch weg. Ich sagte es ja schon oben: das ist Kulturimperialismus und -protektionsmus in Reinkultur. --Matthiasb (CallMeCenter) 11:33, 10. Jun. 2010 (CEST)

Und: wer oder was legt fest, was die wichtigen Sprachen sind? Wird he: ar: ausblenden dürfen oder umgekehrt? Die Spanier wollen die Portugiesen nicht mehr sehen? Ich frage mich, wie man überhaupt auf den Gedanken kommen kann, solche technische Spielereien machbar zu machen. --Matthiasb (CallMeCenter) 11:42, 10. Jun. 2010 (CEST)

Was die wichtigen sind hat YMS doch gesagt: die nach Artikelzahlen großen WPs. Ausblenden heißt doch nur das sie eingeklappt sind, wie es auch beim Vector-Skin möglich ist, sie sind aber doch nicht weg, so dass ich nicht verstehe wo das Problem ist. Die meisten Sprachen sind für die meisten doch uninteressant/irrelevant, die sie eh nie anklicken würden - außer vielleicht um Interwikis zu korrigieren -, da kann man die auch standardmäßig eingeklappt lassen. Wer dann bspw. gerne in der Bengali-Wikipedia ließt kann sich diese doch trotzdem bevorzugt anzeigen lassen. Aber wer nur sporadisch mal auf andere Sprachversionen geht, z.B. um Interwikis zu korrigieren oder sonst was, den wird es nicht umbringen einen Klick mehr zu machen. Das neue Feature wird wohl häufig eher Zeit sparen da man die Links der häufiger nachgefragten Wkipedias – die Nachfrage sollte wohl mit der Größe der Wikipedia korrelieren, siehe Zugriffszahlen – bei beliebten Themen im Artikel nicht mehr aus 70, 100 oder mehr Sprachversionen raussuchen muss. --Mps 12:14, 10. Jun. 2010 (CEST)

So sehe ich das auch. Die Beschränkung auf gehaltvolle interwikis ist schlichtweg Anwenderfreundlichkeit gegenüber 99,9% der Leser. Wenn sich das jetzt gemäß MatthiasB Kulturimperialismus nennt, dann bin ich stolz darauf, Kulturimperialist zu sein und mich für die breite Masse der Anwender einzusetzen, anstelle bizarre Minderheitenförderung zu betreiben und wikis in den meisten Lesern völlig unbekannten Sprachen und meist auch ohne irgendwelche bedeutsamen Inhalte zu protegieren.-- · peter schmelzle · d · @ · 12:28, 10. Jun. 2010 (CEST)

Wenn "wichtige Interwikis" bedeuten würde "alle ausser den Botnet-Wikis wie Volapük" wäre es ja ein brauchbares Feature... --NCC1291 11:20, 10. Jun. 2010 (CEST)

@Mps: Definiere bitte "große WPs". Nach Anzahl der Artikel? Nach Anzahl der Abrufe? Nach Anzahl der Sprecher? Nach Anzahl der angemeldeten und aktiven Benutzer? Nach der Zahl der Admins? Wenn's nach der Zahl der Abrufe geht, würde DE nicht mehr automatisch verlinkt auf EN, ES, FR, egal wo, weil die DE:WP nicht unter den fünf meistabgerufenen WPs ist. Bei den Zugriffszahlen rangieren wir beispielsweise hinter JP:WP. Man hat doch ursprunglich absichtlich eine Sortierung nach ISO-Code gewählt, weil man keine andere nicht diskriminierende Sortierung sah. Wenn's nach der Zahl der Artikel ginge, dann dürften demnächst rund um den Globos die Bots anlaufen.

Interessant, daß ihr alle für eine Zweiklassenwikipedia eintretet. Eigentlich sollten wir das seit einigen Jahrzehnten überwunden haben. Wenn man nicht schon längst sein Bild gemacht hätte über die Teilnehmer an dieser Diskussion und diese als seriös einschätzen würde, könnte man einen völlig falschen Eindruck gewinnen. Wenn das Feature kommt, haben wir ein rassistisches, diskriminierendes, chauvinistisches Feature. --Matthiasb (CallMeCenter) 14:36, 10. Jun. 2010 (CEST)

Komm mal wieder runter. Das ist nicht weniger chauvinistisch, rassistisch oder diskriminierend wie unsere übliche Artikelpraxis, wo wir auch nach Relevanz aussortieren. Da es mittlerweile sehr viele Interwikis gibt, stellt sich eben auch dort die Aufgabe, die relevanten von den irrelevanten zu trennen. Auch bei Weblinks gilt nicht ohne Grund: nur vom Feinsten, und das sollten wir uns bei prinzipiell allen Listen, Lemmata und Links überlegen. Und viele dieser Interwikis sind eben nunmal nicht vom Feinsten, sondern inhaltsarm.-- · peter schmelzle · d · @ · 14:56, 10. Jun. 2010 (CEST)

Interwikis sind keine Weblinks. Sie sind die jeweilige fremdsprachige Version eines Artikels. Es gibt keine irrelevanten Sprachen (sind per se relevant). Ansonsten wüßt ich nicht, daß ein Kaff in Indonesien in der Wikipedia weniger relevant wäre, ein indonesischer Parlamentsabgeordneter genauso wie einer aus der DDR-Volkskammer und der Bürgermeister von, Albany ist genso relevant wie die Oberbürgermeisterin von Heidelberg. Wir werden bei der Relevanz überall die gleiche Latte an. Wir diskriminieren keine fremden Staaten oder Personen in fremden Staaten. Wir sollten auch keine anderen Sprachen diskriminieren. Das Feature, sollte es live gehen, ist Bullshit³. --Matthiasb (CallMeCenter) 15:15, 10. Jun. 2010 (CEST)

Deine Definition der Interwikis stimmt in mindestens zwei Punkten nicht. Sie sind nicht die anderssprachige Version eines Artikels, sondern sie sind ein in einer anderen Sprache verfasster Artikel zum selben Thema, aber eben nicht derselbe Artikel. Außerdem legen anderssprachige Wikipediae andere Relevanzkriterien fest, als wir es tun, da gibt es keine gleiche Messlatte (als Beispiel nur mal der Musikbereich in wiki-en). Nicht zuletzt möchte ich noch darauf hinweisen, dass im Wissenschaftsbetrieb verschiedene Sprachen als Wissenschaftssprachen betrachtet werden, andere jedoch nicht. Das hat weniger mit elitärem Dünkel zu tun, sondern hängt in der Praxis vor allem mit der Verständlichkeit, Verbreitung und Verwertbarkeit der Literatur zusammen. Wer auf Kisuaheli ein Fachbuch über Dendrochronologie verfasst, darf nicht erwarten, dass es weite Verbreitung findet; wer dagegen auf Englisch, Deutsch, Französisch etc. schreibt, wird eher gehört.-- · peter schmelzle · d · @ · 15:47, 10. Jun. 2010 (CEST)

Die Interwikis "erben" die dewiki Relevanzkriterien, weil nur Interwikis vorhanden sind, wenn auch hier lokal ein Artikel existiert. Merlissimo 18:04, 10. Jun. 2010 (CEST)

Eben hast du den Punkt angesprochen: Verständlichkeit, Verbreitung und Verwertbarkeit sind keine elitären Dünkel. Sprachversionen in der Sprachspalte zu bevorzugen, weil sie "große WPs" sind – wurde ja immer noch nicht definiert: bei der Zahl der Sprecher fällt DE durch, liegt nur auf Rang 13, bei der Zahl der Aufrufe streiten wir derzeit mit ES um Rang 3, FR ist da noch in sicherem Abstand – das ist elitärer Dünkel. Es schafft A+-Wikipedias, die direkt sichtbar und erreichbar sind und B-Wikipedias, die zu erreichen es zu klicken erfordert. Nein, die Befürworter des Features können sagen was sie wollen: es ist Diskrimination. Es ist Chauvinismus. Und es ist Rassismus. --Matthiasb (CallMeCenter) 17:59, 10. Jun. 2010 (CEST)

Kann man eigentlich Volapük per JS ausblenden? --Matthiasb (CallMeCenter) 11:33, 10. Jun. 2010 (CEST)

Ja, siehe Benutzer Diskussion:TMg/moveInterwikisToTop.js. An dieser Stelle möchte ich anmerken, dass das Skript ursprünglich auf meinen Wunsch hin geschrieben wurde. :) --32X 12:09, 10. Jun. 2010 (CEST)

Ich finde es eigentlcih als Arroganz anderen gegenüber, wenn man zum einteilen beginnt, wichtige und unwichtige Sprache. Ich möchte sehen, wenn die anderen die deutsche Sprache als unwichtig einstufen, was das für eine geschrei gäbe. Also alle einblenden oder alle ausblenden ist ein muss - sonst ist das diskriminierend hoch ..15:26, 10. Jun. 2010 (CEST)

Was die Wikipedia betrifft so ist die Reduzierung sicher in Ordnung, zumal sich jeder per irgendein Script seine Spezi-Sprachen hinzuschalten kann. Etwas anderes sind Projekte wie Wikisource, wo die Interwikis zu anderen Sprechversionen einen ziemlich anderen (höheren) Wert haben, wobei dies für Leser wichtig ist, und das sind schätze ich zu 99 Prozent nicht angemeldete IPs. Da muss etwas gemacht werden, nicht hier. -jkb- 15:25, 10. Jun. 2010 (CEST)

Hier diese Diskussion zu führen ist völliger Blödsinn, weil alle Leute, die diese Seite betreuen darauf nicht den geringsten Einfluss haben und wir lokal nichts ändern können. Deshalb sollte man die Disk nach Wikipedia:Usability-Initiative/Feedback verschieben - so besteht wenigsten eine geringe Hoffnung, dass die Entwickler eure Meinungen brücksichtigen. Merlissimo 15:32, 10. Jun. 2010 (CEST)

Wird inzwischen eifrig auf der Mailinglist der Foundation diskutiert. --Matthiasb (CallMeCenter) 09:18, 11. Jun. 2010 (CEST)

So ist das nun mal. Man will den Kleingruppen und Minderheiten ja nichts böses. Es ist nur so, dass es so viele von den Kleingruppen gibt. Und da kann eben ihre bloße Anwesenheit schnell mal zum Makel werden. Es will ihnen ja niemand schaden. Alles was man will, ist sie ein bisschen so zu drapieren, dass man als Mehrheitler sie nicht immer sehen muss. In ihrem kleinen zugewiesenen Stadtbezirk dürfen sie ja gerne unbehelligt weiterleben. Solang sie dort unter sich bleiben.

Nein, im Ernst, es ist wirklich Abscheu erregend, wenn Peter Schmelzle hier alles, was keine 100 Millionen Sprecher als europäische Kolonial- bzw. Wissenschaftssprache hat, als "exotisch", "bizarr", "eine Barriere", pauschal "nicht gehaltvoll" und pauschal "unbekannt", nicht-Kleinsprachen-sprechende Nutzer "Normal-User" nennt und Kleinsprachen-Interwikis als etwas auffasst, was man "mitschleppen" muss (was vielleicht ausgemerzt werden muss, um den Wikipedia-Community-Körper zu ertüchtigen...?) und für den exakte Gleichbehandlung "bizarre Minderheitenförderung" bedeutet. --84.143.75.34 19:00, 12. Jun. 2010 (CEST)

Sichter im Nachteil

Moin, offensichtlich haben Sichter kein autopatrol- und patrol-Recht mehr (siehe Spezial:Gruppenrechte). Dadurch werden sie z.B. hier nicht mehr ausgeblendet, wie sonst. Das stört, da man jetzt die neuen Seiten nur noch mühsam auseinanderhalten kann. Das ist Käse, kann jemand das ändern? XenonX3 - (☎:±) 19:46, 15. Jun. 2010 (CEST)

unnötige Einstellung

In den Einstellungen gibt es den Text MediaWiki:Flaggedrevs-prefs-viewdiffs: "Zeige im Versionsvergleich auch den Unterschied zur letzten stabilen Version, wenn der Versionsvergleich bezüglich der neuesten unmarkierten Version angezeigt werden soll ".

Soweit ich das verstanden habe bedeutet das: Ist man z.B. Sichter und die Wikieinstellungen/Seitenkonfiguration erklären geprüfte Version zur stabilen Version bekommt man neben dem diff zur ungesichteten Version auch den diff zur ungeprüften Version. Ist man selber Prüfer bekommt man auch den diff zur ungesichteten Version, falls diese als stabile Version ausgewählt wurden (z.B. dewikiquote)

Macht aber für dewiki weniger Sinn, weil wenn der diff zur ungesichteten (=unmarkierte) Version angezeigt wird dies identisch mit dem diff zur letzten Stabilen Version ist, da bei uns die gesichteten Version immer die stabilen sind. Was machen wir also mit dem Text in den Einstellungen? Merlissimo 12:43, 16. Jun. 2010 (CEST)

„Hier kannst du klicken oder auch nicht, es macht eh nix aus“ – ernsthaft: am besten wäre es, wenn wir das ausschalten könnten (falls nur ein in der Luft hängender Radiobutton möglich sein sollte, ist das allerdings suboptimal. So wie der Text jetzt ist kann man ihn ob der hiesigen Gegebenheiten eh nicht verstehen. – Giftpflanze 13:04, 16. Jun. 2010 (CEST)

Genau die Möglichkeit des Ausschaltes haben wir ja nicht. Merlissimo 13:13, 16. Jun. 2010 (CEST)

Dann etwas sinnvolleres wie "heute ist Freitag, der 13." oder so :-) -jkb- 13:25, 16. Jun. 2010 (CEST)

Die englische Version liest sich: “show the pending changes diff when viewing the latest pending revision”, auf gut Deutsch: „Zeige einen Versionsvergleich (zur letzten gesichteten Version), wenn die letzte ungesichtete Version angezeigt wird.“ Was es dann auch tut. Ist ähnlich, wie wenn man auf den Sichten-Link klickt, nur nicht so komfortabel: Die Versionsgeschichteninformationen werden nicht angezeigt und die Sichten-Schaltfläche befindet sich ganz unten unter dem Artikel. Heißt: Neu übersetzen, was ich auch getan habe: „Zeige einen Versionsvergleich zur stabilen Version, wenn die neueste unmarkierte Version angezeigt wird“ – Giftpflanze 14:09, 16. Jun. 2010 (CEST)

Neue Standardbildbreite: Gallery anpassen?

Die Größendiskrepanz zwischen einzelnen Thumbs und solchen in Galerien ist schon gewaltig. Siehe auch: WP:RB --Rosentod 23:55, 17. Jun. 2010 (CEST)

Extensions monobook vs. vektor

Bei dz wey: zu jeder MediaWiki-Version gehören auch diverse Erweiterungen. MediaWiki haben sich dann viele User zu Hause installiert. Das bringt mich auf einige Frage darüber, wie (düster) die Zukunft aussieht:

1. man hat eine etwas betagte Version und möchte ein Upgrade machen - vermutlich müßte man es jetzt tun, denn demnächst wird wohl (???) MediaWiki mit Vektor default ausgeliefert
2. oder bleiben die Letzten Versionen mit Monobook default zum Download da?
3. und das gleiche mit Erweiterungen: ist meine Vermutung richtig, dass die Monobook-Erweiterungen nicht mit den ab nun neuen Vektor-Versionen nicht kompatibel sind und umgekehrt?
4. falls dem so wäre, muss man sich jetzt hastig alle nicht vorhandenen Erweiterungen als Vorrat downloaden?
5. oder sind meine leienhaften Fragen absurd?

Danke, -jkb- 17:23, 25. Jun. 2010 (CEST)

Hallo jkb, als erstes eine Antwort zu Frage 5: absurd sind deine Fragen nicht. Aber der Reihe nach:

1. Es ist richtig, dass ab Version 1.16 Vector der Standardskin ist. Umstellung auf Monobook direkt nach der Installation in der LocalSettings.php aber natürlich möglich

2. Bis einschließlich Version 1.15.x wird auf ewig Monobook der Standardskin sein

3. Diese Vermutung ist falsch. Alle MediaWiki-Extensions sind mit einer Ausnahme von keinem Skin abhängig. Eine Ausnahme: Die Gruppe der Usability-Extensions. Diese wurden speziell auf Vector hin konzipiert. Es ist natürlich denkbar, dass in Zukunft neue Extensions auf bestimmte Vector-Spezifikationen aufsetzen.

4. Nein. Extensions werden pro MediaWiki-Hauptversion gebrancht. Unter mw:Special:ExtensionDistributor wirst du dir noch für eine seeehr lange Zeit die zu jeder Hauptversion passenden Extensions herunterladen können.

Ich hoffe, das behebt etwas deine Panik ;-) — Raymond ^Disk. 18:26, 25. Jun. 2010 (CEST)

Raymond, danke, das ist beruhigend. Es geht nicht nur um meine private Wiki, sondern ich wollte wissen ob auch z.B. auf Projekten wie Wikilivres sich etwas wesentliches ändern wúrde, wobei man demnächst Entscheidungen treffen müßte. Also, schönes Wochenende, Grüße von -jkb- 18:51, 25. Jun. 2010 (CEST)

Zur Kenntnisnahme: Änderungen an FlaggedRevs

Mir ist gerade der Techblog-Eintrag Upcoming code changes for Flagged Revisions aufgefallen. Verspricht gutes gegen 23 Uhr UTC, da auch einige lokale Fehler behoben werden könnten. Vorallem das Problem der verlinkten statt eingebundenen Bilder (Bug 23415) sollte damit behoben sein. Falls jemand sieht, das die Änderungen live sind, sollte die Vorderseite mal geprüft werden, was dann live ist und entsprechend vermerken. Es wäre gut, wenn sich jemand zeitnah zur angesagten Zeit findet, um das zu prüfen. Vielen Dank. Der Umherirrende 17:41, 14. Jun. 2010 (CEST)

Also um diese Zeit schlafe ich. Soweit ich das bisher beobachtet habe, werden alle FlaggedRevs-bezogenen Änderungen der Vorderseite live gehen. Beim letzten großen Softwareupdate vor einigen Wochen sind diese nämlich ausgespart geblieben. — Raymond ^Disk. 17:53, 14. Jun. 2010 (CEST)

Mit der Einführung der gesichteten Versionen in der englischen Wikipedia... -> Gab es denn diese Einführung wirklich? Und wenn nicht, was ist dann der Grund für die heutigen Änderungen? Die neuen fetten Markierungslinks bei den RC sehen ja furchtbar aus... --S^[1] 09:51, 15. Jun. 2010 (CEST)

Nein, die gesichteten Versionen auf en.wp sind offenbar noch nicht live. Kommt aber (sollte laut techblog gleichzeitig mit der Umstellung hier geschehen, kommt aber laut en.wp erst 24 Stunden später), und im Zuge dessen wurde die technische Basis der FlaggedRevs umfassend überarbeitet. Manche Änderungen heute sind also gewollte Verbesserungen auch bei uns, anderes ist wohl eher ein versehentlicher Nebeneffekt und dürfte in Kürze wieder unserer gewohnten Konfiguration angepasst werden. --YMS 10:04, 15. Jun. 2010 (CEST) Ich muss mich korrigieren: Das techblog schreibt nichts über einen Rollout in der en.wp, sondern verweist in dieser Frage auf die auch von mir verlinkte en.wp-Projektseite ("15 June 2010 at around 23:00 UTC") und den Wikimedia-Blog ("Over the next few days"). --YMS 10:13, 15. Jun. 2010 (CEST)

Da sind einige Änderungen dabei, die eigentlich nur für enwikinews vorgesehen waren. Merlissimo 10:08, 15. Jun. 2010 (CEST)

@S1: Nein, davon kann man nicht wirklich sprechen. Es handelt sich um einen trial, begrenzt auf zwei Monate und 2000 Artikel. --91.64.58.117 11:00, 15. Jun. 2010 (CEST)

Ausstehende Bearbeitungen ist sprachlich meiner Meinung nach nicht zutreffend, richtig wäre Ausstehende Sichtungen oder Noch nicht gesichtete Bearbeitungen. --Geher 10:07, 15. Jun. 2010 (CEST)

Im Testwiki heißt der Button "Seite Speichern" nun "Änderungen übertragen" - das ist viel schlimmer. Merlissimo 10:08, 15. Jun. 2010 (CEST)

In EN wurden die GSV nach vielen öden Diskussionen von flagged protection in pending changes umbenannt. Offenbar haben irgendwelche Übersetzer stur das übersetzt, was ihnen aufgetischt wurde, statt daran zu denken, dass es in DE schon lange etablierte Begriffe für vieles gibt. Würde ich für DE komplett auf die etablierten Termini zurücksetzen. --91.64.58.117 10:55, 15. Jun. 2010 (CEST)

Sehe ich auch so, die alten Begriffe sind etabliert und bekannt, die neuen sind Käse. XenonX3 - (☎:±) 10:57, 15. Jun. 2010 (CEST)

Kann man die [ausstehende Bearbeitungen]‎ in der Beochachtungsliste bitte noch blinkend machen und mit einem animierten GIF versehen? </ironie> --JuTa Talk 11:03, 15. Jun. 2010 (CEST)

ACK S1 und Jutta: diese farbig-fetten Markierungslinks bei den RC sehen in der Tat furchtbar aus. Irgendeine Chance, das auszublenden? --NiTen ^(Discworld) 11:04, 15. Jun. 2010 (CEST)

Müssen wir eigentlich jeglichen farblichen und unübersichtlichen Dreck von en: übernehmen? Wie Geher schon richtig bemerkte, muss es Ausstehende Sichtungen heißen. Das einzige, was farbig aufdringlich protzt, sind die gelb markierten wird überprüft-Buttons. Und da wundern sich einige, warum wikipedia mal wieder langsamer wird und die Zugriffszahlen einbrechen. Ich sehe das Ganze schon seit der Einführung des neuen Skins an den zurückgehenden Neuen Artikeln in vier Portalen (Südamerika, Australien, Internationale Literatur, Deutschsprachige Literatur) - ein paar der zuvor aktivsten Artikelautoren (darunter eine IP) schreiben gar nichts mehr. --Laibwächter 11:11, 15. Jun. 2010 (CEST)

Wenigstens heißt es seit ein paar Minuten wieder [sichten] statt [Ausstehende Bearbeitungen]. Und die Kackbalkenfarbe dort bitte entfernen, ich finde den Button auch ohne den Quark. XenonX3 - (☎:±) 11:14, 15. Jun. 2010 (CEST)

Die Texte sind nicht das Problem, die können wir bis zum Update morgen ändern. Da werden sich die Übersetzer im Laufe des Tages was überlegen. Aber am Layout können wir lokal weniger machen. Merlissimo 11:17, 15. Jun. 2010 (CEST)

@XenonX3: Ich habe den Hintergrund in der MediaWiki:Common.css entfärbt und den Text wie früher auf „Sichten“ geändert. — Raymond ^Disk. 11:21, 15. Jun. 2010 (CEST)

Danke --Geher 11:22, 15. Jun. 2010 (CEST)

Vielen Dank :D XenonX3 - (☎:±) 11:23, 15. Jun. 2010 (CEST)

Dem Dankeschön schließe ich mich an. Übrigens: Entwurf bearbeiten machte ebenfalls mehr Sinn - und die Schaltflächen sind jetzt in Monobook weiter von einander entfernt. --Laibwächter 11:30, 15. Jun. 2010 (CEST)

Vielleicht noch entfetten? Gruß,--Tilla 2501 11:25, 15. Jun. 2010 (CEST)

Eine andere Frage ist, was passiert mit der Meldung? G'rad wollte ich nachfragen, ob sie, wenn ich da auf "verbergen" klicke, wieder kommt wenn eine weitere Seite ungesichtet ist, und nun aber verschwand die Meldung von sich alleine, obwohl die beobachtete Seite nach wie vor ungesichtet ist. Ist es vielleicht zeitlich begrenzt/gesteuert? -jkb- 11:36, 15. Jun. 2010 (CEST)

Sie ist wegen dieser Änderung weg. --Steef ³⁸⁹ 11:44, 15. Jun. 2010 (CEST)

Aha. Wenn dismissable bewirkt, dass sie alleine von sich aus ist, dann ist es klar. Denn auf "verbergen" habe ich, wie geesagt, nicht geklickt. Danke, -jkb- 12:14, 15. Jun. 2010 (CEST)

Wegen dieser Änderung ist jetzt aber nicht nur diese eine Sitenotice weg, sondern alle lokalen Sitenotices. Und nimmt man stattdessen die korrekte ID, ist zwar wieder nur die Sitenotice weg, die auch weg soll, aber nicht komplett, sondern der [Verbergen]-Link bleibt in der Luft hängen (vgl. MediaWiki Diskussion:Common.css#Ausblendung der Flagged-Revisions-Backlog-Sitenotice).

Man könnte stattdessen mal was anderes versuchen und die Nachricht entfärben, entfetten und entrahmen, dann wäre sie weniger aufdringlich und es bliebe kein verwirrender [Verbergen]-Link zurück. Alternative wäre eine Konfigurationsänderung, dass sie gar nicht generiert wird, aber das würde wohl Änderungen der FlaggedRevs-Erweiterung erfordern. --Entlinkt 13:28, 15. Jun. 2010 (CEST)

So ein M.... Ich habe jetzt die korrekte ID #mw-fr-watchlist-pending-notice genommen. Aber damit bleibt der [Verbergen]-Link weiterhin sichtbar. — Raymond ^Disk. 13:45, 15. Jun. 2010 (CEST)

Ich stimme Entlinkt zu. Farbe, Fett und Rahmen sollten weg. Das sieht furchtbar aus. liesel 16:39, 15. Jun. 2010 (CEST)

Es ist inzwischen wieder ausgeblendet (und zwar jetzt wirklich, ohne die anderen Sitenotices mit auszublenden), aber ich bin mit der Lösung nicht zufrieden. Es ist nicht ordentlich, eine Sitenotice so auszublenden, dass es nicht korrekt funktioniert (aber so, dass es auch funktioniert, ist es unmöglich). Schön wär's, wenn es in der Extension selbst konfigurierbar wäre, ob die Notice überhaupt erzeugt wird. Bis dahin könnten wir uns auch überlegen, auf die Ausblendung (notgedrungen) zu verzichten und dafür die Formatierung komplett zu entfernen. --Entlinkt 16:44, 15. Jun. 2010 (CEST)

Ich würde die Information nicht verstecken, sondern einfach unauffälliger gestalten. Es wird sicher Benutzer geben, die dieser Hinweis freut. Und die Benutzer die es stört wissen auch, wie man ihn ausblendet. Die Nachteile überwiegen aber. Der Umherirrende 21:30, 15. Jun. 2010 (CEST)

Ja, ich zum Beispiel ;-) Damit sieht man nämlich auch ungesichtete Versionen, die älter sind als der Inhalt der Beobachtungsliste. Kann ich das für mich lokal wieder irgendwie einschalten? --PaterMcFly Diskussion ^Beiträge 11:11, 30. Jun. 2010 (CEST)

Ja, mit .fr-watchlist-pending-notice { display: block; }. Gegen Augenkrebs hilft die erweiterte Version:

.fr-watchlist-pending-notice {
	display: block;
	padding: 0;
	margin: 0;
	border-style: none;
	background-color: transparent;
}
.fr-watchlist-pending-notice b {
	font-weight: normal;
}

In dieser Form würde ich das (ggf. probeweise) vielleicht sogar als Standardeinstellung vorschlagen, weil der freischwebende [Verbergen]-Link doch sehr irritierend ist. --Entlinkt 05:03, 3. Jul. 2010 (CEST)

Hmmm, also der Verbergen-Link ist mir bisher noch gar nicht aufgefallen. Ansonsten: Danke, hab ich inzwischen auch schon rausgefunden. Falls möglich sollte man sowas vielleicht bei den persönlichen Einstellungen wählen können? --PaterMcFly Diskussion ^Beiträge 09:02, 3. Jul. 2010 (CEST)

Systemtext

Ich bin total fertig - auch geistig [5]!

Die Übersetzungen wurden von mir nachgearbeitet unter folgendem Leitsatz "Änderungen werden als gesichtet (=basic status) oder geprüft (=quality status - nicht aktiv auf dewiki) markiert (=basis oder quality) und dann als stabile (stable) Version angezeigt"

Vorher wurden Änderungen als gesichtet oder geprüft freigegeben/überprüft/markiert/akzeptiert und als angezeigte/stabile/freigegebene Version veröffentlicht. Merlissimo 20:04, 15. Jun. 2010 (CEST)

Aufgrund der vielen englischen Wörtern und der nur sehr leichten Abstufung, habe ich dieses nie gemacht, da es sehr schwierig ist einheitliche Übersetzung der Wörter hinzubekommen. Von einer Akzeptanz hier ganz zu schweigen. Mit deinem Leitsatz scheint das aber gut funktioniert zu haben. Der Umherirrende 21:27, 15. Jun. 2010 (CEST)

Beim Sichten einer Seite bekommt man die Aufforderung: Bitte überprüfe alle nicht überprüften Änderungen (siehe unten), die seit der neuesten freigegebenen Version gemacht wurden. Gegebenenfalls musst du zunächst diese Bearbeitungen nachvollziehen oder rückgängig machen. (Hervorhebung von mir). Sollte wohl auch hier sichten heißen. Die momentane Wortwahl liegt semantisch zu sehr in der Nähe der geprüften Versionen, die nach Hilfe:Gesichtete und geprüfte Versionen in de-WP gar nicht aktiv sind. Oder doch? Bitte alle Texte auf prüfen/geprüft usw. durchsuchen. --Herzi Pinki 21:30, 15. Jun. 2010 (CEST)

(darunter heißt es dann gleich: Markiere Version (statt sichte Version). --Herzi Pinki 21:33, 15. Jun. 2010 (CEST))

Das meiste mussim translatewiki mit "markieren" übersetzt werden. Auf dewikiquote kann dies sichten oder prüfen bedeuten. Meine Änderungen sind aber noch nicht live. Nach dem Update hatte ich vor noch einige Nachrichten, von markieren auf sichten zu ändern, was aber nur lokal möglich ist, weil wir hier keine geprüften Versionen besitzen. In der von der erwähnten Nachricht ist dies aber nicht nötig, da es für's Nachsichten und Nachprüfen schon zwei unterschiedliche Nachrichten gibt. Merlissimo 21:53, 15. Jun. 2010 (CEST)

Check ist die Handlung/das Knopf-drücken, wodurch eine Version zu einer Reviewed Revision macht. Check wurde vorher mit überprüfen übersetzt, was aber zu Verwechslungen mit validated revision (geprüfte Version) führte. Nun heißt check markiere und reviewed revision Markierte Version, wobei ich dadurch bei Sätzen wie "click 'check' to review this revision" etwas kreativer sein musste (check und review in einem Satz gab's zum Glück nur zweimal in den über 300 Nachrichten). Kontrollieren ist ja bereits zur das patrol-Feture belegt ist. Merlissimo 21:42, 15. Jun. 2010 (CEST)

Deine Änderungen wurden bislang noch nicht als stabile Version gekennzeichnet. Es gibt ältere Bearbeitungen, die noch überprüft werden müssen. - ich meinte das überprüfen im ersten und im letzten Beitragn (im Sinne von sichten). --Herzi Pinki 21:55, 15. Jun. 2010 (CEST)

Ok, habe deine Anmerkung verstanden, du hast es bereits überall auf sichten geändert, aber die Änderung ist noch nicht live. Dann warte ich ein bisschen. lg --Herzi Pinki 21:58, 15. Jun. 2010 (CEST)

So mit rev:68107 sind die Änderungen im Translatewiki nun live. Zudem habe ich das wichtigen Meldungen von markiert auf gesichtet geändert, weil wir hier keine geprüften Versionen haben. Hoffe ich habe nicht übersehen - ansonsten hier melden. Merlissimo 00:24, 16. Jun. 2010 (CEST)

Begründung und Buttonanordnung

Ich brauche das Begründungsfeld ja nicht, aber es hatte eine positive Nebenwirkung: Der zu drückende Button war vorher rechts, wo man die Maus eher hat (wegen der Tabs). könnte irgendwer die Buttons also wieder da hin verfrachten? :) --TheK? 20:00, 15. Jun. 2010 (CEST)

Browserfenster schließen

Seit den neuen FlaggedRevs kann man beim Firefox nach dem Sichten das Browserfenster nicht mehr mit Strg+W schließen. --Fomafix 21:45, 15. Jun. 2010 (CEST)

Es ist sehr nervig. Vor der Aktualisierung hat es funktioniert. Mir war so, als ob es früher sogar während des Speichervorgang nicht möglich war zu schließen, erst danach wieder. Hat jemand eine Ahnung, wie so etwas gemacht wird und woran es liegen könnte, dass die Tasten jetzt nicht mehr funktionieren? --Fomafix 12:56, 17. Jun. 2010 (CEST)

Ich habe dazu soeben Bugzilla:24013 aufgemacht. — Raymond ^Disk. 12:59, 17. Jun. 2010 (CEST)

Kann es sein, dass dieser Effekt nur auftritt, wenn sich der Fokus noch auf dem Sichten-Schalter befindet? Wenn der Fokus dort weg ist, kann ich die Registerkarte mit Strg+W schließen. — Lecartia Δ 13:16, 17. Jun. 2010 (CEST)

Ja. Habe ich soeben auch im Bug angemerkt. — Raymond ^Disk. 13:25, 17. Jun. 2010 (CEST)

Update: Aaron hat heute Nacht den Fehler behoben: rev:68192. Live ist er aber noch nicht. — Raymond ^Disk. 07:53, 18. Jun. 2010 (CEST)

Ist live und funktioniert. Danke. Das Fester lässt sich wie früher erst schließen, nachdem die Sichtung gespeichert ist. --Fomafix 14:18, 20. Jun. 2010 (CEST)

Wann kommt common.css/js?

In Revision 63300 aufgrund von Bug 10183 Anfang März eingeführt, aber offenbar noch immer nicht live, obwohl's sinnvoll gewesen wäre, das zur Vectoreinführung bereits gehabt zu haben. Weiß jemand, ob und wann das kommt? Momentan jedenfalls verweisen noch unzählige Seiten im Hilfe- und Wikipedia-Namensraum auf die monobook.css/js (entweder ultimativ oder mit Vermerk "meist", oder mit nachfolgender Aufzählung aller anderen Varianten). Das gehört durchgesehen, und dabei wäre es natürlich günstig, dann gleich das generische Konstrukt verwenden zu können. --YMS 00:07, 7. Jul. 2010 (CEST)

Das Problem ist wohl die Fehleranfälligkeit. Wenn du mit deiner monobook.js alles zerstörst, kannst du mal eben mit useskin auf ein anderes Skin wechseln und z.B. unter modern deine monobook.js wieder reparieren. Diese Möglichkeit existiert bei common.js nicht mehr. Alternativlösung steht in Bug 22971/6908. Merlissimo 00:21, 7. Jul. 2010 (CEST)

Die Revision ist aber schon reviewed (trotz dieser Bedenken) und kam bloß leider zu spät für das letzte Update. Finde ich sehr bedauerlich, weil es eine der Änderungen ist, die zu einer weitgehend reibungslosen Skinumstellung noch fehlte und es sehr umständlich macht, Dinge zu dokumentieren, Benutzern zu helfen usw., aber ich fürchte, das kommt nicht vor dem nächsten „großen“ Update. Und wann das nächste große Update sein wird, weiß keiner so genau, aber es kann durchaus ein paar Monate oder ein halbes Jahr dauern. Das letzte war am 9. April. Gruß --Entlinkt 00:24, 7. Jul. 2010 (CEST)

rote Ausrufungszeichen

Jemand eine Idee wie wir bugzilla:24053 lösen wollen? Ich kenne mich dort zu wenig im Code aus. Patrol ist ansonsten hier quasi deaktiviert/ausgeblendet. Merlissimo 18:58, 2. Jul. 2010 (CEST)

Hmm... komisches Problem, das mir aber schon lange nicht mehr aufgefallen ist. Jedenfalls sollte mE das Ausrufezeichen für ungesichtete Seiten bleiben, nur für die Namensräume, wo es keine Sichtung gibt, natürlich nicht. Vom Code habe ich allerdings keine Ahnung. Vielleicht könnte man da was "faken"? Das bisherige Ausrufezeichen mittels css ausblenden und ein neues für die gesichteten Versionen einführen? Die Information, dass es da was zu Sichten gibt, steht ja an der Stelle sicher zur Verfügung. --PaterMcFly Diskussion ^Beiträge 18:14, 7. Jul. 2010 (CEST)

revisionmove

Ist die Änderung wirklich schon live oder bin ich nur zu doof für ein revisionmove? Gruß,--Tilla 2501 20:16, 2. Jul. 2010 (CEST)

Ich frage mich, wofür diese Funktion nötig sein soll... XenonX3 - (☎:±) 20:17, 2. Jul. 2010 (CEST)

Dito. Auch ich sehe keine Veränderung im Interface, die mir dies ermöglichte. Grüße, —DerHexer (Disk., Bew.) 20:20, 2. Jul. 2010 (CEST) P. S.: @Xenon, siehe https://bugzilla.wikimedia.org/show_bug.cgi?id=21312#c0

Ah, ok. Für Versionsgemische ist es natürlich sinnvoll. Aber es scheint mir selbst für Admins noch zu mächtig zu sein, damit kann man ja gewaltig Unfug treiben. XenonX3 - (☎:±) 20:23, 2. Jul. 2010 (CEST)

Wir können ja auch beschließen, das Recht es wie beim XML-Import nur auf Bedarf zu vergeben. Persönlich wäre ich aber froh, wenn ich zum Zusammenführen oder Trennen von Versionsgeschichten nicht den Artikel kurzzeitig hin und her verschieben oder löschen müsste. --32X 20:51, 2. Jul. 2010 (CEST) PS: Kann mich mal jemand auf dem Testwiki zum Admin schlagen?

Wenn dann gehört das nur an die Gruppe der Importeure vergeben, weil die sich auf dem Gebiet mit Versionstrennung schon teilweise auskennen und das alles techninsch recht kompliziert ist. Entscheidend ist ja, dass die diffs danach ja nicht mehr zum Autor passen könnten, was nie passieren darf. Kombiniert mit import kann man das aber z.T. lösen. Ich glaube aber dennoch nicht, dass wir es hier je bekommen. Merlissimo 21:11, 2. Jul. 2010 (CEST)

Einfach auf m:SRP beantragen, dann wird dies schon ein Steward vergeben. ;o) Grüße, —DerHexer (Disk., Bew.) 21:59, 2. Jul. 2010 (CEST)

Hi. Ich habe diese Funktion gebastelt, wohl wissend dass sie selten benötigt wird. Das neue RevisionDelete-Schema wird das alte Schema aber langfristig nur dann vollständig ersetzen können, wenn es gleich mächtige Funktionen bereit stellt. Revisionmove ist kann mit dem alten Schema durch „Löschen–Verschieben–Wiederherstellen“ und „Löschen-selektives Wiederherstellen–Verschieben–Wiederherstellen“ umgesetzt werden – durch das selektive Wiederherstellen ist dieser Prozess im alten Schema ähnlich intransparent wie bei revisionmove (es ist nicht sichtbar, welche Versionen betroffen sind, nur die Anzahl). Man könnte durchaus darüber nachdenken diese Funktion auf einen kleinen Kreis zu beschränken: Einerseits, weil man viel Unsinn damit bauen kann, und zwar auch aus Versehen. Andererseits weil es wie gesagt ein sehr selten benötigtes Feature ist. Gruß, --Church of emacs D B 00:27, 3. Jul. 2010 (CEST)

Ergänzungsfrage: Wäre es nicht sinnvoll, endlich eine Möglichkeit zu programmieren, Versionen (oder ganze Artikel) zu kopieren? Das würde wohl deutlich häufiger verwendet als einzelne Versionen zu verschieben. --PaterMcFly Diskussion ^Beiträge 09:24, 3. Jul. 2010 (CEST)

Steht irgendwo (aber leider nicht sehr weit vorne) auf meiner ToDo-Liste. Durch eine Möglichkeit Versionen zu kopieren könnte man sich den Export und anschließenden Importupload sparen. --Church of emacs D B 10:08, 3. Jul. 2010 (CEST)

Ja, und es wäre auch von der Anwendung her deutlich weniger problematisch was mögliche (Benutzer-)Fehler betrifft. Importupload wurde ja bewusst auf eine sehr enge Benutzergruppe reduziert, copy könnte wohl gleich behandelt werden wie Transwiki. --PaterMcFly Diskussion ^Beiträge 18:09, 7. Jul. 2010 (CEST)

Nicht öffentliche Entwürfe

Ich glaube mich zu erinnern, dass mal nicht öffentliche (Artikel-)Entwürfe angekündigt worden waren. Weiss jemand, was daraus geworden ist? --Leyo 20:43, 20. Jul. 2010 (CEST) PS. Extension:Drafts gefunden.

Schlummert selig, was ich sehr schade finde. Es muss erst ein Lead-Developer der Foundation ein Codereview durchführen, und daran mangelt es :-/ — Raymond ^Disk. 21:20, 20. Jul. 2010 (CEST)

Ja, schade… --Leyo 22:53, 20. Jul. 2010 (CEST)

Im testwiki ist die Erweiterung schon recht lange aktiv. Fast schon zu lang. Merlissimo 23:09, 20. Jul. 2010 (CEST)

Wir haben den Code in einem nicht öffentlichen Wiki aktiv. Er macht keine erkennbaren Probleme. Ich finde ihn sehr angenehm und er hilft, die Datenbank klein zu halten, da weniger Zwischenstände gesichert werden. --Purodha Blissenbach 13:24, 23. Jul. 2010 (CEST)

Änderungen am Suchfeld

Hallo, für „SimpleSearch - moving away from our label-based placeholder text […]” steht umseitig die Frage im Raum, was sich dadurch verbessert hat. Aus Sicht der Barrierefreiheit ist es jetzt besser, weil die Lupe nun ein Bild ist, das den Alternativtext „Volltext“ hat. Somit ist die Suchfunktion besser verständlich. Zuvor gab es keinerlei Alternativtext. Wer die Anzeige von Bildern abgeschaltet hatte, bekam außerdem keinerlei Hinweis mehr auf ein drückbares Element, daher der Umschwung auf eine button-Umsetzung. — Lecartia Δ 10:06, 23. Jul. 2010 (CEST)

Kleine Änderungen

(Vorschau) (Softwareneuheit) Die Benutzereinstellung „Eigene Änderungen standardmäßig als geringfügig markieren“ wurde entfernt. Die Möglichkeit individuelle Bearbeitungen mit „Nur Kleinigkeiten wurden verändert“ zu markieren besteht weiterhin.

Wer hat sich denn das ausgedacht?? Ich glaube nicht, dass ich bei jedem Edit (und das meiste, was man macht, sind nunmal Kleinigkeiten) dieses Feld händisch ankreuzen werde. Das Ende vom Lied wird sein, dass dann kaum noch geringfügige Bearbeitungen als solche gekennzeichnet sind. Kann man sich irgendwo gegen diese Softwareverschlechterung wehren? --Thogo 22:03, 4. Aug. 2010 (CEST)

Geht wohl nur über Bugzilla und da brauche ich dir ja nicht zu sagen, wie lange es dauert, bis sich jemand drum kümmert... -- Chaddy · D – DÜP – 22:13, 4. Aug. 2010 (CEST)

rev:69337 enthält den Hinweis auf bugzilla:24313 und Umgehungsmöglichkeiten. --Entlinkt 23:18, 4. Aug. 2010 (CEST)

Ich finde den Ansatz der Entwickler, so wenig Einstellungen zu haben, wie möglich ein Schritt in die falsche Richtung. Natürlich überfordern viele Einstellungen, die Neulinge, aber wenn es ihn überfordert, dann ändert er nichts und man kann die Einstellung für die Fortgeschrittenden drin lassen. Die Vorbelegung einer CheckBox ist eine häufige Einstellungsart in vielen Programmen. Gerade durch die Einstellungen und die eigenen js/css ist MediaWiki individuell einstellbar, was von großem Vorteil ist.

Wie schon von vielen gesagt, ein soziales Problem kann man nicht mit Änderung der Technik beheben. Natürlich wäre es schön, wenn das "K" immer im guten Sinne gebraucht wird, aber davon kann man nicht ausgehen oder es wird zu viel Aufwand sein, das zu erreichen. Ich denke, jeder hat schon mal vergessen, die CheckBox wieder zu leeren, wenn er größere Änderungen gemacht hat. Der Umherirrende 09:15, 5. Aug. 2010 (CEST)

HTML-Anker

Heißt das „(aktuell)“ hier, dass mw:User:Simetrical/Id test bereits funktionieren sollte? Tut es nämlich nicht, ich seh immer noch Anker wie „abc_.D7.93.D7.90.D7.A4_ascii-[…]“. (FF 3.5.9/X11) Viele Grüße, —mnh·∇· 09:45, 6. Aug. 2010 (CEST)

Sorry für die blöde Formulierung. "Aktuell" ist das alte Verhalten auf mw:User:Simetrical/Id test. Translatewiki läuft jedoch bereits mit der neuestens Version, so dass unter translatewiki:User:Raymond/Id test das zukünftige Verhalten ausprobiert werden kann. — Raymond ^Disk. 10:55, 6. Aug. 2010 (CEST)

Ist die Einstellung $wgExperimentalHtmlIds eigentlich unabhängig von $wgHtml5? Wenn ja, ist anzunehmen, dass in den Wikimedia-Wikis das eine ohne das andere aktiviert wird? $wgHtml5 ist ja in Mediawiki standardmäßig aktiviert und Translatewiki behält die Standardeinstellungen bei, aber Wikimedia nicht. --Entlinkt 15:14, 6. Aug. 2010 (CEST)

Antwort selbst gefunden, siehe rev:61772. --Entlinkt 22:33, 13. Aug. 2010 (CEST)

Liquid Thread

Die Einführung geht ja lustig vonstatten: Am Samstag noch ohne Namensraum-Nummer, aber für alle Wikis eingeführt. Irgendwann wurden dann die Nummern 90-93 nachgereicht. Heute rudert man offensichtlich zurück und nimmt die Namensräume bei allen bis auf wenige wieder raus. Auf daß mein Commit-Log wieder anschwillt :) - @xqt 08:22, 20. Aug. 2010 (CEST)

Dir soll halt nicht langweilig werden.... ;) --Guandalug 08:48, 20. Aug. 2010 (CEST)

:P Jetzt sind alle wieder raus. Mal gucken wann man wieder umkehrt.  @xqt 10:07, 20. Aug. 2010 (CEST)

Solange sie an den Namensraumnummern für Liquids herumfummeln, geht's noch. Vielleicht vertauschen sie es nicht mit den Nummern für Wikipedia Diskussion: ... -jkb- 10:10, 20. Aug. 2010 (CEST)

Wo kann man noch mehr im Bezug auf die de:Wiki erfahren? Bin aktuell nur auf das hier gestoßen Commons:Commons:LiquidThreads. -- Perhelion 20:13, 20. Aug. 2010 (CEST)

WP:LiquidThreads und WP:WikiProjekt LiquidThreads --Der Umherirrende 20:19, 20. Aug. 2010 (CEST)

mysql 4->5.1

Domas hat die mysql Serverversionen für dewiki vor eingien Tagen umgestellt und keiner hat's bemerkt. ;-) Merlissimo 21:34, 25. Aug. 2010 (CEST)

Was bringt das eigentlich für Vorteile (Bezogen auf das Projekt)? Der Umherirrende 21:24, 30. Aug. 2010 (CEST)

Laut dem Artikel MySQL ist die Version 5 auch schon wieder fünf Jahre alt, die Version 4 ist sogar von 2003. Wieso wurde bislang eine sieben Jahre alte Version genutzt und erst jetzt ein Upgrade installiert, dass es schon seit fünf Jahren gibt? :S -- Chaddy · D – DÜP – 22:39, 30. Aug. 2010 (CEST)

Domas, der bis vor kurzem für MySQL gearbeitet hat, hatte die Version 4 extrem auf die Bedürfnisse der Wikimedia angepasst gehabt, so dass ein Umstieg auf Version 5, seinen Worten nach, keinen Vorteil brachte. Warum jetzt, weiß ich nicht.

@Merlissimo: Ich habe es auch nur über Special:Version festgestellt, dachte aber, es sei in meinem Urlaub passiert. Und im Server Admin Log finde ich auch keinen passenden Eintrag. — Raymond ^Disk. 23:01, 30. Aug. 2010 (CEST)

@Chaddy: „Wieso wurde bislang eine sieben Jahre alte Version genutzt und erst jetzt ein Upgrade installiert, dass es schon seit fünf Jahren gibt?“—Ganz einfach: größere RDBMS-Updates sind nie ohne Risiko, gerade bei „unseren“ riesigen Datenbanken und der hohen Anfragenlast. Neuer heißt nicht zwangsläufig performanter (angesichts des für Open Source typischen Feature Creeps eher das Gegenteil) und wenn sich 5.1 unter Last anders als das WMF-angepasste 4.0 verhält, kann das im Extremfall zu längerem Komplettausfall führen. Würdest Du das riskieren wollen, wenn die bestehende Installation doch mehr oder minder gut funktioniert?
5.1 ist übrigens vom November 2008, hatte zu der Zeit 55 kritische (crash oder falsche Ergebnisse) + 180 schwerwiegende Bugs und arge Performanceprobleme. De facto versteh ich bis heute nicht, weshalb man von den Spendengeldern kein vernünftiges™ Heavy-Duty-Datenbanksystem (DB2, Oracle) kauft und weiter mit MySQL hantiert. Viele Grüße, —mnh·∇· 00:37, 31. Aug. 2010 (CEST)

@Raymond Wir hatten im irc gequqtscht, ob vereinzelt Fehler aufgetreten sind, nachdem Domas zunächst nur den Haupt-Slave von s5 umgestellt hatte. Nachdem dies nicht der Fall war, wurde auch der Rest inkl. Master umgestellt. Hatte mich selbst gewundert, dass es nicht im log steht.

Datenbankupdates in Major-Versionen kann man nicht mit normalen Softwareupdates vergleichen. Diese werden nur recht selten gemacht und kommen oft einer kompletten Systemumstellung gleich. Das sich z.B. viele Firmen im letzten Jahr von der populären DB2 Version 7 verabschiedet haben liegt an der fehlenden 64 Bit-Unterstützung und nicht an der eigentlich veralteten DB2 Version. mysql 4 wird immer noch weiterentwickelt.

Hier scheinen einige MariaDB für Zukunftüberlegungen interessant zu finden. Merlissimo 01:04, 31. Aug. 2010 (CEST)

Anscheinend wurde s1 (en) komplett, sowie s2 (misc), s4 (commons) und s5 (de) zum Teil geupdatet, es fehlen noch s3 (small) und s6 (fr/ja/ru) (keine Garantie für diese Informationen, das Update ist derzeit im Gang und daher gibt es laufend Veränderungen. Und Bugs). Domas hat seinen Arbeitgeber in der Versionierung verewigt ;-)
Ehrlich gesagt bin ich ein wenig überrascht, dass das so still über die Bühne geht. Aber mir solls recht sein :) --Church of emacs D B 01:38, 31. Aug. 2010 (CEST)

Ist für mich auch das erste Mal, dass ich so eine leise und schleichende Umstellung erlebe. Aus eigener Erfahrung kenne ich das nur so, dass ein Firmensystem am Freitag nachmittag stillgelegt wird und dann ein ganzes Team das Wochenende damit verbringt am Montag morgen den Angestellten ein funktionierendes System präsentieren zu können. Internetshops machen das Nachts. Im laufenden Betrieb hingegen ist das sehr schwierig. Das man zuerst die Slaves umstellt und dann erst den Master kannte ich auch noch nicht. Merlissimo 03:41, 31. Aug. 2010 (CEST)

Domas hat zu dem Thema übrigens gebloggt. Das Posting erklärt auch, was es mit dem facebook in der Versionsnummer auf sich hat. --Entlinkt 00:20, 1. Sep. 2010 (CEST)

Sehr interessant, danke für den Link! Ich hab die ganze Sache mal bei den Neuheiten eingetragen --Church of emacs D B 15:01, 1. Sep. 2010 (CEST)

Resourcenloader und Benutzeranpassungen

Moin. Wird es diese Änderung irgendwo zum Testen geben? Ich fürchte, dass der Resourcenloader zunächst einmal das Ende vieler aktuell installierter Scripte sein wird. Wenn Funktionen aus wikibits nicht mehr garantiert werden (können), fallen für eigene Scripte Funktionen wir addOnloadHook() oder importScript() aus. Diese Funktionalität selber schreiben zu müssen hielte ich für extrem ungeeignet.... --Guandalug 16:40, 9. Sep. 2010 (CEST)

Als erstes wird sicherlich das Translatewiki den RessourceLoader nutzen. Ich kann das Wiki aber aktuell nicht updaten, da er noch zuviele deftige Bugs hat. Please hold the line ... — Raymond ^Disk. 16:53, 9. Sep. 2010 (CEST)

Halte uns auf dem Laufenden. Und im Zweifelsfall muss ich halt im Translatewiki "testen"... :S --Guandalug 16:57, 9. Sep. 2010 (CEST)

Eigentlich wäre das vielleicht mal eine gute Möglichkeit, die JavaScript-Abhängigkkeit etwas zu senken und stattdessen eher dieselbe Funktionalität über direktes Einfügen ins DOM über Extensions herbeizuführen. --The Evil IP address 23:23, 9. Sep. 2010 (CEST)

Viel Glück, die Extensions durch den Review zu bekommen. Wahrscheinlicher ist es, dass die Klamotten auf jQuery umgeschrieben werden (müssen) --Guandalug 23:56, 9. Sep. 2010 (CEST)

Das Sandwiki vom Translatewiki läuft schon mit dem Ressourceloader: http://translatewiki.net/sw/Main_Page . Das Wiki betreue ich aber nicht, das ist Niklas' Sandbox für die Weiterentwicklung der Translate-Extension. — Raymond ^Disk. 15:17, 10. Sep. 2010 (CEST)

Update: Translatewiki läuft seit Sonntag mit dem Ressourceloader. — Raymond ^Disk. 14:22, 14. Sep. 2010 (CEST)

tif

14:05 Uhr wurde noch kein Thumb angezeigt. liesel 14:06, 14. Sep. 2010 (CEST)

Purgen hat auch nix gebracht :-( Das tiff sollte man jemand analysieren. Könnte kaputt sein oder ein nicht unterstütztes Unterformat sein. — Raymond ^Disk. 14:24, 14. Sep. 2010 (CEST)

Das Tif funktioniert, ich kann es herunterladen und bei Irfanview problemlos öffnen. Es ist 1:1 aus der LOC übertragen. liesel 14:28, 14. Sep. 2010 (CEST)

Die Datei hat offenbar 19,7 MB. Das gab es schon gerade vor kurzem, dass thumbs von solchen großen Dateien nicht erzeugt wurden. Liegt es nicht daran? -jkb- 14:40, 14. Sep. 2010 (CEST)

Wenn das nicht funktioniert, dann frage ich mich, wozu man tifs benötigt. Wenn ich kleinere Dateien haben will, muss ich dann eine Komprimierung mit jpg oder png drüber laufen lassen. liesel 14:42, 14. Sep. 2010 (CEST)

das hier geht

Wenn man sich die Thumbnail-URL [6] direkt anguckt, erscheint die Fehlermeldung: Error creating thumbnail: The resolution of the source file is too large. No thumbnail will be generated.. Dass große TIFFs nicht gehen, war klar, das ist genau so wie bei PNGs. Aber dass das nicht im WIki angezeigt wird, ist allerdings doof - ich glaube aber, dass das ein allgemeines Problem ist, nicht Spezifisch für TIFFs. Wäre evtl einen Bug-Report wert. -- Daniel Kinzler (WMDE) 14:47, 14. Sep. 2010 (CEST)

Was ist denn die maximale Auflösung? (Irgendwo stand was, aber wo…?) Viele Grüße, —mnh·∇· 15:11, 14. Sep. 2010 (CEST)

(BK) Bis Bug-Reports abgearbeitet werden kann das allerdings dauern...

So machen tiffs aber keinen Sinn. Die haben es ja meistens so an sich, dass sie ziemlich riesig sind... So ist also in der Theorie eine Funktion vorhanden, die in der Praxis nicht wirklich nutzbar ist... -- Chaddy · D – DÜP – 15:13, 14. Sep. 2010 (CEST)

//BK// max. Aufl.: Schwach in Erinnerung: 20 MB, also nur knapp mehr als 19,7. -jkb- 15:14, 14. Sep. 2010 (CEST)

TIFFs sind ja nicht unbedingt unkomprimiert, die meisten verwenden eine verlustfreie Kompression. Sogar JPEG-Kompression ist in TIFF-Dateien möglich. Und die meisten TIFFs, die wir auf COmmons haben, sind nicht zu groß - also scheint es einen praktischen Nutzen zu geben.

Es greifen verschiedene Limits (die dienen dazu, die Server vor Überlast zu schützen). Die greifen für (fast) alle Bilder:

• upload limit: 100 MB
• max pixel: 1.2 megapixel (nicht für jpeg)
• max image size: 100 MB
• max shell memory: 100 MB
• max shell time: 50 sekunden

wenn eines der Limits überschritten wird, bricht der Renderer ab.

Es gibt einen besseren Renderer (VIPS) für TIFFs, der braucht weniger Speicher, und man könnte größere Bilder erlauben. Der müsste aber auch erstmal getestet werden - ein Feature Request auf Bugzilla wäre dafür sinnvoll. -- Daniel Kinzler (WMDE) 15:45, 14. Sep. 2010 (CEST)

Tiffs werden aber v. a. deshalb verwendet, damit man Bilder möglichst ohne Kompression in sehr hoher Qualität abspeichern kann. Gerade deshalb werden tiffs dann häufig auch ziemlich riesig...

Etwas OT: Die 100-MB-Begrenzung (die ja früher bei 20 MB war, wenn ich mich noch recht erinnere) schränkt auch die Nutzbarkeit von Videos ein. Längere (natürlich freie) Videos in vernünftiger Qualität können wir deshalb nicht nutzen. Gerade dieser Vorteil würde uns aber klassischen Enzyklopädien unterscheiden. Multimediale Inhalte werden im digitalen Zeitalter immer wichtiger. Deshalb sollte gerade auch in dieser Hinsicht Wikipedia weiter verbessert werden (hier wäre, im Gegensatz zu Skin-Spielereien, wenigstens ein wirklicher Bedarf da...). -- Chaddy · D – DÜP – 17:09, 14. Sep. 2010 (CEST)

Na ja, ich hab's nicht ausprobiert, aber selbst mit Theora dürften 100MB für einige Minuten in 480p reichen – durchaus ansehnlich und mehr als genug für Artikel. Da gibt's imo wichtigere Baustellen (z.B. mediawiki extensions für matplotlib und graphviz, damit Graphen und Diagramme einfacher erstellt werden können und direkt im Quelltext editierbar sind. Träumen darf ich ja…). Aber: Ein kleines Megapixelchen erlegt irgendwie den Hauptnutzen von Tiff (verlustfreie Kompression) – bei max 1200x1000 konvertiert man dann doch besser gen jpeg. Schade. —mnh·∇· 19:39, 14. Sep. 2010 (CEST)

Die Begrenzung der Upload-Größe ist durch Eigenheiten von HTTP und PHP bedingt, an einer lösung wird gearbeitet.

Was das Speichern ohne Kompression angeht - warum würde man das tun wollen? Das wäre reine Platzverschwendung. Sinnvoll ist es, ggf verlustfreie Kompression zu verwenden - also nicht JPEG; In TIFF-Dateien wird dafür miest LZW verwendet. Aber man kann auch einfach PNG nutzen, das ist auch verlustfrei.

Meiner Meinung nach wird TIFF vor allem aus zwei Gründen benutzt: Farbmenagement für die Druckvorstufe (YMCK, Gamma, all der Kram), und mehrere Bilder pro Datei. Da sind einige TIFFs mit mehreren hundert Bildern (Buchseiten) auf Commons. Die können wir im Moment leider nicht verarbeiten, sorry. Dafür muss man (noch?) auf DjVu ausweichen. Ist eigentlich ohnehin das bessere format für gescannten Text. -- Daniel Kinzler (WMDE) 15:59, 16. Sep. 2010 (CEST)

WD:WPDK#Eigener Namensraum für Dateikategorien?

Ich weiss, ich bin hier nicht ganz richtig, aber es sind hier viele technisch versierte Benutzer aktiv. Von diesen würde mich ein Feedback zur technischen Realisierbarkeit interessieren. --Leyo 16:27, 4. Okt. 2010 (CEST)

Softwareupdate der Vorschau

Ist eigentlich irgendwann mal geplant, die doch schon sehr lange Liste der Vorschau live zu schalten? -- 217.238.164.134 19:49, 4. Okt. 2010 (CEST)

Wie dort schon erwähnt: bald, vielleicht auch nie.  @xqt 20:11, 4. Okt. 2010 (CEST)

Planungen der Lead-Developer gehen in Richtung November, kann natürlich auch Dezember werden. — Raymond ^Disk. 20:31, 4. Okt. 2010 (CEST)

@xqt Das habe ich schon gelesen, ist aber über Monate hinweg, nicht sonderlich hilfreich.

@Raymond Danke. Da kommt ja langsam Freude auf. -- 217.238.164.134 20:35, 4. Okt. 2010 (CEST)

Export per API funktioniert nicht

Ich frage mal hier, da ich hoffe, das technisch versierte Leute diese Seite beobachten und mir helfen können.

Ich möchte ein paar Seiten per API exportieren. API-Abfrage. Wenn ich aber nun export anhänge. Bekomme ich nur den Header des Exports, aber keinen Seiteninhalt. Die Seiten alle herauszulesen und dann über Spezial:Export gehen, funktioniert. Was mache ich falsch? Hat jemand diese Funktionalität schonmal genutzt? Über Hinweise würde ich mich freuen. Der Umherirrende 20:08, 7. Okt. 2010 (CEST)

Nach ein bisschen Trial & Errror: Du musst die Liste als generator verwenden: API-Abfrage. Du musst noch gaplimit wieder auf max hochsetzen, da es aber womöglich Leute gibt, die einfach mal so auf den Link klicken, will ich denen und den Hamstern das alles ersparen. --Schnark 09:14, 8. Okt. 2010 (CEST)

Danke für den Hinweis. So ist das Ergebnis wie erwartet, jetzt habe ich eine funktionierende Abfrage. Es kommt mir aber trotzdem komisch vor, dass bei meinem Link der Header geschrieben wird, aber nicht der Inhalt. Mal schauen. Der Umherirrende 19:35, 8. Okt. 2010 (CEST)

Ich habe mich entschieden, die Frage an die Entwickler zu stellen: Bug 25463. Der Umherirrende 20:46, 8. Okt. 2010 (CEST)

data-sort-value

Bei den Zukunftsaussichten wird erwähnt, dass man Tabellenzellen, im geparsten Quelltext also TD-Tags, mit dem Attribut "data-sort-value" versehen kann und dass die Tabellenzeilen dann danach sortiert werden können. Dazu würde ich gerne wissen:

• HTML 5 wird frühestens im März 2011 als Standard kommen. Wird dieses Feature hier erst danach eingeführt oder kommt es eher ?
• Kann die Software dann nur Data-Werte des TD-Tags berücksichtigen ?

Wenn ja, dann gibt es ein Problem: Die bisherigen Workarrounds wie z.B. die Ländervorlagen mit Flagge, oder die Fussballvorlagen arbeiten mit einem zum (geparsten) Vorlagenquelltext gehörenden, festen Sortierschlüssel und nicht mit einem direkt im Artikel stehenden.

Genaueres Beispiel: Bei den Workarronuds sieht ein typischer HTML-Quelltext so aus: Im Artikel steht:

| {{V-Name}}

und in Vorlage "V-Name" steht:

<span style="display:none;">SORTIERSCHLUESSEL</span>Irgendetwas

Daraus generiert der Parser:

<td><span style="display:none;">SORTIERSCHLUESSEL</span>Irgendetwas</td>

Das TD-Tag wird hierbei aus dem Artikelquelltext geparst, das Span-Tag mit dem Sortierschlüssel aus dem Quelltext der Vorlage. Um daraus einen HTML-Quelltext mit Data-Atrribut für die T-Zelle zu machen:

<td data-sort-value="SORTIERSCHLUESSEL">Irgendetwas/td>

muss der Sortierschlüssel aber in den Artikel:

| data-sort-value="SORTIERSCHLUESSEL"| {{Vorlagenname}}

Ich habe bedenken, dass man in Zigtausend Artikeln den Tabellenquelltext rund um die Einbindung ändern kann.

Die Software sollte daher nicht nur ein Data-Attribut im TD-Tag
(<td data-sort-value="SORTIERSCHLUESSEL">Irgendetwas</td>)
richtig sortieren können, sondern auch das Data-Attribut eines leeren Span-Tags am Anfang des Zellinhalts
(<td><span data-sort-value="SORTIERSCHLUESSEL" />Irgendetwas</td>), denn dann muss man nur die Vorlagen anpassen. ÅñŧóñŜûŝî (Ð) 01:09, 14. Okt. 2010 (CEST)

Oder der data-sort-value wird zum MagicWord, das irgendwo in der Zelle stehen kann. Vorstellen würde ich mir das wie defaultsort, also {{DATASORT:xyz}}. Das Attribut wird dann auf das darüberliegende Element, hier also die <td>, weitergereicht.

Eine anderen Möglichkeit wäre, dass in der Sort-Vorlage „einfach“ ein | mit ausgeliefert wird. Probleme würden bei sämtlichen Zellen auftreten, die bereits Attribute haben, auch wenn das eigentlich möglichst wenige sein sollten.

|style="background:#555;"| {{vorlage|xyz}} → |style="background:#555" {{vorlage|xyz}}

Daher sollte man am besten gleich ein neue Vorlage erschaffen, die dann auch text-align und Co. automatisch setzen kann, wenn sie in die Zellenattribute hineinragt.
meint -- ✓ ^Bergi 16:22, 14. Okt. 2010 (CEST)

Eine Vorlage wäre ja noch zu meistern, aber es geht auch um alle ca. 700 Ländervorlagen mit Flagge, alle Einbindungen von Fbm, Fbf und Fbi (Diese rufen die Ländervorlagen auf) und wohl noch ein paar andere. Die erzeugen nur einen String ohne jede Tabellensyntax und da eine einzubauen bewirkt garantiert Chaos. Dieses Durchreichen scheint die beste Lösung zu sein, aber das bekommen die Programmierer m.E. garantiert nicht auf die Reihe ... ÅñŧóñŜûŝî (Ð) 16:31, 14. Okt. 2010 (CEST)

RessourceLoader für Monobook

Vor einigen Tagen habe ich umseitig angekündigt, dass der RessourceLoader auch für den Monobook-Skin zum Einsatz kommt. Eigentlich hatte ich mit einem Aufschrei der Skriptler gerechnet. Hat es denn niemand gelesen oder spielt es keine Rolle (mehr)? — Raymond ^Disk. 09:04, 20. Okt. 2010 (CEST)

Glaubst du ernsthaft, nach der globalen Androhung des ResourceLoaders schockt uns das noch? Vorlage:Smiley/Wartung/;)  PDD ist eh schon vorgewarnt, dass seine Scriptsammlung (mehr als nur partiell) umgeschrieben werden muss - das hat automatisch Auswirkungen auf Monobook. Im Endeffekt ist das dann sogar besser, so kann man für beide "großen" Skins parallel reparieren. Und was ich vond er Änderung generell halte, schreibe ich mal lieber nicht öffentlich nieder. --Guandalug 09:10, 20. Okt. 2010 (CEST)

Proteste gabs verhalten schon, aber an falscher Stelle als Randbemerkung. Scheint halt als Gott-gegeben akzepiert zu sein ;)  @xqt 09:38, 20. Okt. 2010 (CEST)

Der RessourceLoader wurde auch vor obiger Änderung schon im Monobook-Skin verwendet, sowohl Mediawiki:Monobook.js als auch Special:MyPage/monobook.js wurden vom RessourceLoader ausgeliefert. Die skins/monobook/main.css war eine der letzten verbliebenen Dateien, die statisch eingebunden wurde. Die einzigen, die sich über diese Änderung beschweren könnten, sind die Araber und andere RTL-Sprachler, die in Zukunft keine handerlesene CSS-Datei bekommen, sondern nur eine maschinell gespiegelte. --Schnark 09:52, 21. Okt. 2010 (CEST)

War zumindest nicht verhalten gemeint. Unverständnis bis stinksauer trifft's eher. Grüße, —DerHexer (Disk., Bew.) 18:12, 21. Okt. 2010 (CEST)

ResourceLoader

Da ich selber einige Javascripte für Wikipedia geschrieben habe und mich dabei etwas intensiver mit dem ResourceLoader auseinander gesetzt habe, hier ein paar mahnenden Worte an alle mitlesenden (und eigentlich auch an die nicht mitlesenden) Skriptbastler:

• Eine wichtige Änderung ist die Tatsache, dass alles, was bisher an globalen Variablen und Funktionen herumschwirrte, als deprecated gelten wird. Dies betrifft irgendwelche obskuren, ohnehin nur intern benutzten Funktionen ebenso wie die SAJAX-Bibliothek (die einige nutzen, z. B. der BKL-Check) und besonders wikibits.js. Siehe dazu (besonders zu den Alternativen) mw:ResourceLoader/JavaScript Deprecations. Betroffen ist außerdem der Alias $j für jQuery (in Zukunft $) und alle globalen Variablen (wgFooBar, in Zukunft mediaWiki.config.get('wgFooBar'). Dass all das als deprecated gelten wird, muss einen erst einmal nicht weiter bekümmern, aber man sollte es auch nicht aus dem Auge verlieren, dass man irgendwann ohne dieses Zeug auskommen muss.

• Einzige Funktion, die sich anders verhalten wird, ist addOnloadHook. Bisher wurden die damit zum Aufruf vorgemerkten Funktionen zu dem Zeitpunkt aufgerufen, zu dem der Browser beim schließenden </body>-Tag angelangt war. In Zukunft wird der Aufruf beim load-Ereignis stattfinden. Zwischen diesen beiden Zeitpunkten liegt insbesondere die Ladezeit der Bilder, je nach Seite erfolgt der Aufruf also stark verzögert. Abhilfe schafft meist die jQuery-Funktion $() (bzw. noch $j()), die ebenso wie addOnloadHook als Argument eine Funktion entgegennimmt. Der Aufruf erfolgt dann etwas später als bisher mit addOnloadHook, aber nur minimal (was in den meisten Fällen mehr nützt als schadet). Ein weiteres Problem ist die Tatsache, dass alle Skripte am Ende geladen werden. Bei einer modularen Programmierweise kann es vorkommen, dass $() die Funktion nicht auf die Wartebank setzt, sondern direkt ausführt, was dann ein Problem ist, wenn man darauf vertraut, hinterher noch die Konfiguration o. Ä. überschreiben zu können. Das kann auch jetzt schon passieren, ich habe allerdings nicht getestet, ob sich die Verschachtelungstiefe, ab der das auftritt eventuell verkleinert. Beispiel:

alert('vorne');
$j(function(){alert('$j');});
addOnloadHook(function(){alert('aOH');});
alert('hinten');

• • MediaWiki 1.16, direkter Aufruf: vorne - hinten - aOH - $j
  • MediaWiki 1.16, Aufruf in einem über (evt. mehrere) importScript (o. ä.) Skript: vorne - $j - aOH - hinten
  • MediaWiki 1.17, direkter Aufruf: vorne - hinten - $j - aOH
  • MediaWiki 1.17, indirekter Aufruf: vorne - $j - hinten - aOH

• for (var x in array)-Schleifen werden nicht mehr funktionieren, da Arrays eine compare-Funktion hinzugefügt wird, sodass x nicht nur alle Indizes durchläuft, sondern auch den Wert compare, array[x] ist dann undefined. Wer so etwas verwendet, sollte also rechtzeitig den Code umschreiben. Betroffen ist z. B. das Gadget Navigationspopups, in en ist der Code schon geändert, er muss nur noch übernommen werden (oder direkt von en eingebunden werden). „Normale“ for-Schleifen und for-in-Schleifen für Objekte funktionieren wie bisher.

• Einen großen Vorteil hat der ResourceLoader aber für Skriptbastler: Es wird in Zukunft nicht nur jQuery zur Verfügung stehen, sondern bei Bedarf auch viele Plugins, darunter alle offiziellen jQuery-UI-Plugins. Syntax z. B.: mediaWiki.loader.using('interner.plugin.name', onReady); --Schnark 09:25, 18. Okt. 2010 (CEST)

Danke für den Hinweis. Wo findet man denn die Codes bzw. die Dokumentation des neune JS-Codes, insbesondere von „Plugins“ und diesem mediaWiki-Objekt? mw:ResourceLoader/Design Specification scheint sich ja eher an die PHP-Entwickler zu richten, wenn ich das richtig verstanden habe. Das Problem mit dem Überschreiben der Konfiguration wird vor allem bei den Gadgets (z.B. Extraeditbuttons) auftreten, oder? for(x in array)-Schleifen hab ich zum Glück schon aufgrund (lokalen) Experimenten mit prototyping rausgeworfen.
meint -- ✓ ^Bergi 17:46, 20. Okt. 2010 (CEST)

Ich habe oben noch einen Fehler korrigiert (mediaWiki.loader.using). Die einzige mir bekannte Dokumentation ist der Javascriptcode selbst, zu finden unter resources/mediawiki/mediawiki.js. Ich glaube kaum, dass die Programmierer die globalen Variablen schnell abschalten, aber sobald man sie dann über mediaWiki.config erreicht, sehe ich keinen Grund, die Gadgets nicht entsprechend anzupassen. --Schnark 09:46, 21. Okt. 2010 (CEST)

„Einen großen Vorteil hat der ResourceLoader aber für Skriptbastler“ … welch freundliche Umschreibung dafür, dass ich so ziemlich alle meine Skripte umschreiben darf … Wo ist der eingestellte Entwickler, der dies macht? Oder war es schon immer so intendiert, stundenlange Arbeit durch Umstellungen zu torpedieren? —DerHexer (Disk., Bew.) 18:15, 21. Okt. 2010 (CEST)

Ich will ja jetzt eigentlich nichts sagen, aber meine Skripte (sind natürlich deutlich weniger als deine) liefen in einem Testwiki mit ResourceLoader auf Anhieb ohne Probleme, mit zwei Ausnahmen: Einmal die erwähnte for-in-array-Schleife, einmal fehlte ein jQuery-Plugin, das bisher auf Verdacht allen Vector-Benutzern geliefert wurde, ob sie es nun brauchten oder nicht, das aber in Zukunft nur noch dann kommt, wenn man es wirklich braucht oder explizit anfordert. Für Leute, die nicht von Hand DOM-Manipulationen vornehmen wollen etc. ist der ResourceLoader eine Erleichterung. --Schnark 09:31, 22. Okt. 2010 (CEST)

Das Hauptproblem dürfte bei PDDs Monobook liegen.... das verlässt sich auf die Anwesenheit der wikibits.js - Funktionen UND darauf, dass es schon zur Ladezeit der Seite ausgeführt wird ..... das wird lustig. --Guandalug 09:37, 22. Okt. 2010 (CEST)

wikibits sollte (zumindest solange die Drohung "are planned to be […] quarantined, and eventual removed" noch nur eine Drohung ist) vor der eigenen monobook.js etc. geladen werden, zumindest sehe ich das in meinen Beispielen so. Wenn nicht, müsste man alles in eine Funktion verpacken und dann schreiben mediWiki.loader.using('mediawiki.legacy.wikibits', funktion_die_wikibits_braucht);. Bei den ganzen document.write gebe ich dir allerdings recht, das wird eine Menge Arbeit, die auf DOM-Manipulationen umzuschreiben. Eventuell tut es aber eine einfache Ersetzung von document.write durch $j('body').append. --Schnark 10:10, 22. Okt. 2010 (CEST)

Ich denke, es wird weniger arg werden als vielleicht befürchtet.

• In der genannten Quelle heißt es:
  This will not change until we are 100% ready to turn off legacy globals
  

  var LEGACY_GLOBALS = true;
  

  Dies wird ja wohl erst nach längerer Zeit (oder nie) abgeschaltet werden, die JS-Variablen also erstmal verfügbar bleiben. prettytable lebt ja auch noch.
• Die wikibits.js wird man international, sicherlich aber deutschsprachig umschreiben können und müssen, im Sinne einer Emulation des Status quo. Realistischerweise von Benutzern zurzeit benötigte Funktionen werden simuliert, wie addOnloadHook (würde ja dann wohl einfach zum sofortigen Aufruf durchgereicht werden) oder ein importScript("[[Benutzer:Ich/MeinExtra.js]]") endlich mal mit der Möglichkeit eckiger Klammern (WhatLinksHere) lassen sich simulieren, offenbar mit .load(). Konstruktiv wäre es, einmal zusammenstellen, was „normale“ Benutzer (nicht Skin- oder Server-Programmierung) eigentlich brauchen.
• Schwieriger wird sicher der Fall, dass jemand im Benutzerskript wirklich vor dem Laden des BODY aktiv sein muss; da sehe ich zwingend nur importStylesheet, weitere unbedingt notwendige Fälle sollten mal konkret und explizit benannt werden, vielleicht lässt sich daraus ein fundierter Wunsch an die Entwickler im Sinne eines BeforeLoadHook ableiten. Warum Extraeditbuttons nicht erstmal das Laden (nicht Rendern) des DOM abwarten können, ist mir nicht ganz klar. Teils scheinen mir Programmierpraktiken Skin- und Browserversions-abhängig zu sein.
• for (var x in array) ist allgemein eine gefahrengeneigte Programmierpraxis in JS, die bei dieser Gelegenheit zufällig mal wieder auffliegt.

--PerfektesChaos 10:41, 22. Okt. 2010 (CEST)

Mit dem Gadget funktioniert das m.W. bisher so:

1. Das Gadget wird initialisiert.
2. Im Userscript können Settings überschrieben werden
3. (die Standard-Editbuttons werden direkt im Inlinescript initialisiert)
4. onload: Das Gadget schreibt nach den (evtl. überschriebenen) Settings das Buttonsarray um
5. onload: die Standardfunktion schreibt die Buttons ins Array

Was da jetzt bei den oben beschriebenen „davor-$()-aOH-danach“-Verwirrungen passiert, mag ich mir nicht ausmalen. Könnte das vielleicht mal jemand testen? -- ✓ ^Bergi 15:11, 22. Okt. 2010 (CEST)

So wie ich das verstehe, läuft das Gadget volgendermaßen ab:

1. Das Inlinescript definiert die Standardbuttons (dass es im Moment noch an der Stelle steht, an der die Knöpfe dann eingefügt werden, hat soweit ich sehen kann keine tiefere Bedeutung)
2. Das Gadget überschreibt (initButtons) die Standardbuttons nach Bedarf, ausgeführt durch addOnloadHook.
3. edit.js fügt die Buttons ein, ausgeführt durch hookEvent(load).
4. Das Gadget überschreibt (extendButtons) einige der Funktionen, ausgeführt durch hookEvent(load).

Damit das in Zukunft funktionieren soll, müsste zum einen addOnloadHook(initButtons); durch $(initButtons); (bzw. im Moment noch $j(initButtons);) ersetzt werden (damit das vor dem Einfügen der Buttons geschieht), zum anderen alle for-in-array-Schleifen (vermutlich 3 Stück) umgeschrieben werden.

Etwas anderes nochmal: Bei meinem Test wurden sämtliche Skriptdateien so früh ausgeführt, dass es gerade noch rechtzeitig war, um document.write funktionieren zu lassen. Eventuell ist es also gar nicht nötig, dabei etwas umzuschreiben. --Schnark 09:24, 23. Okt. 2010 (CEST)

Bei der Bildansicht per gallery werden soviele Bilder dynamisch nebeneinander gesetzt

Zu der neuen Funktion (noch in Vorschau) habe ich zwei Anmerkungen.

Erst mal Danke - darauf habe ich schon länger gewartet. Finde die "festen" Einstellungen der Anzahl der Bilder störend, da sie nur auf einen Bildschirmtyp optimiert sind. Sie sollten nun jetzt mit der neuen Funktion ebenso verpönt sein, wie feste Bildgrößensteinstellungen bei Einzelbildern.

Zweitens kenne ich die Funktion von den Kategorien auf Commons (ich glaube gelesen zu haben, dass dies von einem JavaScript-Hack kommt). Dort werden bei der Bildschirmauflösung 1024x768 fünf Bilder in der waagerechten ohne Probleme angezeigt. Ohne Probleme, heißt dass kein Scrollbalken erscheint. Bei der Testseite User:Raymond/gallery kommen aber bei 1024x768 nur vier Bilder. Kann man das nicht noch verbessern/optimieren?

Übrigens funktionieren beide Arten gut, wenn man im Browser die Tast STRG+ "+" oder STRG+ "-" (Ansicht zoomen) benutzt. --Atamari 19:58, 29. Nov. 2010 (CET)

Guten Morgen, was mich zu dieser Frage mal interessieren würde ist, woher das Tag dann weis wie viele Dateien dynamisch nebeneinander gesetzt werden können/dürfen, damit es für den User passend ist. Gibt ja eigentlich auch nur zwei Möglichkeiten: Erstens, man nimmt es aus den persönlichen Einstellungen im Bereich Aussehen dort Dateien, aber was wäre dann mit nicht angemeldeten Benutzer. Zweitens man lässt eine Cookie-Abfrage nach der computervoreingestellten Bildschirmauflösung laufen. Was wird hier denn ausschlaggebend sein? mfg --Crazy1880 07:03, 30. Nov. 2010 (CET)

Das funktioniert (zumindest bei Raymonds Beispiel) durch eine geschickte Nutzung von CSS. Die Bilder sind in einer "Liste", und die Gallery sagt (über CSS): Listenelemente nebeneinander. Wenn das nächste Element nicht mehr daneben passt, wird halt 'ne neue Zeile begonnen. Kein Cookie, kein JavaScript, nur Browserinteraktion. Das Tag "weis" also gar nix, das interessiert sich auch nicht dafür - das delegiert die Aufgabe an den Browser. --Guandalug 08:54, 30. Nov. 2010 (CET)

Ah, auch eine schöne Lösung, könnte mir ja gefallen, danke für die Auskunft --Crazy1880 10:58, 30. Nov. 2010 (CET)

Aktualisierung der gesichteten Versionen

Hi, ist diese Aktualisierung die Ursache für die kaputten Diffs? In Diffs werden keine Kategorien mehr angezeigt, Gadgets (wie die BKL-Anzeige) funktionieren nicht mehr und Interwikilinks gibt es auch keine mehr. Ich empfinde das als schwerwiegenden Fehler und schlage einen Revert dieser "Aktualisierung" vor. --h-stt !? 23:45, 27. Nov. 2010 (CET)

Ja, ist sie. Siehe FzW. --Guandalug 00:37, 28. Nov. 2010 (CET)

Mich stört das auch extrem. Ich muß regelmäßig den Artikel durch einen weiteren Klick neu laden (und sehe dann den Diff. nicht mehr). Kann man das bitte wieder zurücksetzen. --Mogelzahn 09:51, 29. Nov. 2010 (CET)

Mit den ganzen Problemen, die das mit Addons macht: +1 --Guandalug 10:00, 29. Nov. 2010 (CET)

Und nun? Wer kümmert sich? Ich kenne mich bei Meta eher weniger aus. --Mogelzahn 10:18, 1. Dez. 2010 (CET)

Sichtung von Kategorien

Das Tool von Magnus Manske wurde noch nicht für die Erweiterung angepasst. Gibt es eine andere (einfache) Möglichkeit, alle ungesichteten Kategorien innerhalb eines Kategoriebaums zu erfassen? --Leyo 00:04, 29. Nov. 2010 (CET)

Hmm. Muss ich meinem Bot auch noch beibringen. Du siehst mich extrem begeistert. --Guandalug 00:21, 29. Nov. 2010 (CET)

Es wäre vielleicht sinnvoll, zu Beginn die Anzahl an ausgegebenen Kategorien zu begrenzen. --Leyo 09:58, 29. Nov. 2010 (CET)

Warum? Alle Kategorien des Baumes, der betrachtet wird.... 's gibt doch keine Redaktion mit einem SOOOOOO großen Kategoriebaum..... ;) --Guandalug 10:00, 29. Nov. 2010 (CET)

Chemie: 872; Schweiz: 2117 --Leyo 10:06, 29. Nov. 2010 (CET)

Schon klar. "Wirtschaft" will ich ja gar nicht erst wissen --Guandalug 10:16, 29. Nov. 2010 (CET)

Gibt es Statistiken darüber, welcher Prozentsatz der Kategorien projektweit schon (erst)gesichtet wurde? --Leyo 14:35, 30. Nov. 2010 (CET)

Du meinst nicht zufälligerweise Spezial:Markierungsstatistik? Viele Grüße --Saibo (Δ) 16:44, 30. Nov. 2010 (CET)

Doch. Nur hatte ich die Seite gerade nicht mehr gefunden. *schäm* --Leyo 16:47, 30. Nov. 2010 (CET)

Weiss jemand, ob Magnus informiert ist und daran ist, seine Sichtungs-Tools zu ergänzen? --Leyo 15:45, 2. Dez. 2010 (CET)

Weiß ich nicht. Aber, da Magnus ja AFAIK zur Zeit eh keine Zeit hat (siehe Commonshelper), hast du vielleicht mit dem ähnlichen Tool von Hannes mehr Erfolg: http://toolserver.org/~hroest/flagged.php Angepasst scheint es aber auch noch nicht zu sein. Viele Grüße --Saibo (Δ) 19:29, 2. Dez. 2010 (CET)

Diff angezeigt wird, jetzt per API geholt und per JavaScript eingeblendet.

ist dem immer so oder ist das nur wie im artikel steht bei "sehr großen seiten" und leider gottes bei "sehr normalen seiten" das gegenteil? Zumindest bei mir ist es gefühlt langsamer als sonst?! ...Sicherlich ^{Post / FB} 10:03, 30. Nov. 2010 (CET)

Generell. Der Inhalt "unter" dem Diff kommt via API. Dass es langsamer ist, wundert mich kaum.... ansonsten siehe FzW. --Guandalug 10:05, 30. Nov. 2010 (CET)

wenn dich nicht wundert das es langsam ist, warum steht dann vorne Dies bringt Geschwindigkeitsvorteile bei sehr großen Seiten - sollte man ergänzen; und nachteile für alle anderen? ...Sicherlich ^{Post / FB} 11:44, 30. Nov. 2010 (CET)

Na ja, wenn man die Serverarchitektur kennt, dann fragt man sich ja wirklich, ob es sinnvoll war, die Artikel über die (ohnehin nicht so prickelnden) API-Server zu ziehen, statt wie bisher..... Aber ich mische umseitig nicht mit und ändere da Ankündigungen --Guandalug 11:56, 30. Nov. 2010 (CET)

(Disclaimer: Für die Änderung bin ich nicht verantwortlich.) Der umseitige Bug, auf Grund dessen die Änderung stattfand, lautet auf Make review load faster by speeding up display of old revisions. Daher habe ich dies auch umseitig so kommuniziert. Von mir aus kann der Zusatz vorne entfernt werden, aber aus Gründen der Übersichtlichkeit halte ich nichts davon, dass Vor- und Nachteile für verschiedene andere Szenarien kommentiert werden. Wenn es ein Problem darstellt (mir war es persönlich noch nicht so negativ aufgefallen), bitte einen neuen Bug öffnen. — Raymond ^Disk. 12:06, 30. Nov. 2010 (CET)

Würde ich auch nie behaupten. Ich schlage nicht den Boten der schlechten Nachricht.... du machst hier einen guten Job, wir WISSEN wenigstens, warum was hakt

Bugs sollte es schon geben (nicht wegen der Geschwindigkeit, aber wegen der anderen Nachteile), das mit den API-Servern steht auch schon auf Bugzilla. --Guandalug 12:12, 30. Nov. 2010 (CET)

joh wie Guandalug ich schlage Sicherlich nicht Raymond (der ist auch größer als ich; trau ich mich gar nicht :D ) - aber das mit der geschwindigkeit entferne ich mal ;) ... bzgl. Bugs und Bugzilla; könnte man wenn man kann. ich kapier nicht wie das funktioniert. das melden da ist was für technik-versteher ...Sicherlich ^{Post / FB} 12:33, 30. Nov. 2010 (CET)

achso; unhöflich wie ich bin; danke euch natürlich für die Info! ...Sicherlich ^{Post / FB} 12:34, 30. Nov. 2010 (CET)

Könnte mir bitte jemand die betreffenden Bug-IDs raussuchen? Ich hab jetzt keine gefunden. -- ✓ ^Bergi 18:01, 30. Nov. 2010 (CET)

Unter anderem Bug 25289 - ja, das ist der, wo das ganze Zeug erst eingeführt wurde. Kurz vor ENde steht was bzgl. API-Server. --Guandalug 18:58, 30. Nov. 2010 (CET)

Danke, ich meinte v.a. die Fehler-Bugs. Über das nicht-Funktionieren der Gadgets hat sich ja noch gar keiner aufgeregt? Wie auch immer, ich habe jetzt mal per Bugzilla:26175 ein vollständiges Rückgängigmachen dieser „Funktionalität“ beantragt.
meint -- ✓ ^Bergi 20:18, 30. Nov. 2010 (CET)

Die Antwort von Aaron Schultz auf die Bug-Meldung ist - wenn meine rudimentären Englisch-Kenntnisse mich nicht im Stich gelassen haben - gelinde gesagt ziemlich arrogant. --Mogelzahn 10:17, 1. Dez. 2010 (CET)

"Gadgets können halt mal kaputt gehen, wenn die UI erneuert wird. Das passiert." Das ist im Prinzip Aarons Antwort. Und ja, das ist schon etwas arrogant... -- Chaddy · D – DÜP – 13:41, 1. Dez. 2010 (CET)

So hatte ich das auch verstanden, nur mit dem Unterton "was nutzt Ihr auch Gadgets ..." --Mogelzahn 14:04, 1. Dez. 2010 (CET)

Aarons Antwort ist zweigeteilt zu lesen: 1) Das Verschieben des Bearbeiten-Links durch ein Gadget: Da habt ihr die Antwort schon richtig interpretiert. Die UI ändert sich von Zeit zu Zeit, weil sie angepasst werden muss. Und jedes Tool, dass sich auf Screenscrapping/Auslesen des HTML-Codes verlässt, ist dann eben bisweilen verlassen. Und meine Maus hat bisher noch jeden Bearbeiten-Link gefunden, egal ob er links, mittig oder rechts steht. 2) Das Fehlen der Kategorien und Interwikilinks sieht Aaron aber auch als Manko an: I'd agree that the category/IW link and the breakage of local site CSS customizations is particularly annoying. — Raymond ^Disk. 23:03, 2. Dez. 2010 (CET)

Es ist nur nicht so, dass sich nur das UI etwas verändert hat und die Gadgets an die Änderung angepasst werden müssen, sondern die Gadgets werden zur falschen Zeit ausgeführt und es gibt keinen passenden Hook, an den die Gadgets hingehängt werden können. --Fomafix 23:28, 2. Dez. 2010 (CET)

Die müsstest du (zum Teil?) auf WP:FzW finden. Der Thread (ganz oben) ist kaum zu übersehen ;) --Guandalug 20:59, 30. Nov. 2010 (CET)

Änderungen verwerfen

Ich habe eben das neue Feature mal ausprobiert. Ich wollte diese 3 IP-Edits zurücksetzen. (Gut, die eine Zahl hätte ich auch ganz einfach per Hand ändern können, aber ich wollte die neue Funktion testen.)

Also habe ich auf "Änderungen verwerfen" geklickt, und mir wurden auch nur die 3 IP-Edits aufgelistet. Nach dem Bestätigen war aber plötzlich auch die nachfolgende Änderung eines anderen Benutzers mit zurückgesetzt: diff des Verwerfens. Die Zusammenfassungszeile bestätigt meine Intention, nur die 3 IP-Edits zu verwerfen, wie es mir auch angezeigt wurde: "Die 3 ersten Änderungen von 91.96.3.83, die auf die Version 82120215 von ExIP folgten, wurden verworfen". Tatsächlich verworfen wurden aber alle 4 Änderungen. Ist das ein Riesen-Bug oder habe ich da was falsch verstanden? --Stepro 21:04, 2. Dez. 2010 (CET)

Ich glaube es ist eher ein Verständnisproblem. Die Funktion setzt auf die letzte gesichtete Version zurück. Eben auf die, die man sieht, wenn sich die ungesichteten Änderungen ansieht. Bei den ungesichteten Änderungen waren auch die Änderungen von Kleiner Muc enthalten - eigentlich. Oder hattest du die Seite mit der Ansicht der ungesichteten Änderung vielleicht mehr als eine halbe Stunde lang geöffnet, bevor zu auf verwerfen klicktest? Was in dem Fall passiert wäre, weiß ich nicht. Viele Grüße --Saibo (Δ) 22:30, 2. Dez. 2010 (CET)

Wenn das so geplant ist, dass alle Änderungen seit der letzten Sichtung zurückgesetzt werden sollen, dann ist die Ausführung aber ordentlich für den Arm. Wenn mir 3 der 4 Änderungen zum Zurücksetzen angezeigt werden und ich dies explizit durch einen 2. Klick bestätigen muss, dann erwarte ich als Nutzer, dass auch nur genau diese angezeigten und bestätigten Änderungen zurückgesetzt werden. Auch die Zusammenfassungszeile ist dann mehr als irritierend, um nicht zu sagen schlicht falsch. Am Zeitpunkt kann es nicht gelegen haben, ich hatte die Änderung von Kleiner Muc schon gesehen, bevor ich den Diff mit den IP-Änderungen aufgemacht habe. Also irgendwas liegt da für mich im Argen. --Stepro 10:19, 3. Dez. 2010 (CET)

Entschuldige bitte - ich hatte es mir falsch vorgestellt. Ich hatte nicht gewusst, dass der Knopf auch bei der Ansicht von Diffs angezeigt wird. Ich dachte er wurd nur beim kompletten Diff aller ungesichteten Änderungen angezeigt.

Ich hatte eben testweise die aktuelle Version entsichtet um zu testen. Mir dann den IP-diff anzeigen lassen - und ja, es wurde nur angezeigt, dass die drei Änderungen verworfen werden (wirklich "verwerfen" geklickt habe ich dann nicht). Mir scheint es ein Bug zu sein. Viele Grüße --Saibo (Δ) 14:40, 3. Dez. 2010 (CET)

Gemeldet unter bugzilla:26238. --Steef ³⁸⁹ 22:45, 4. Dez. 2010 (CET)

Ah, danke! Es wird also auch schon repariert worden sein. Vorlage:Smiley/Wartung/;-)  (Immer dieser Unterschied zwischen gefixt und live...) --Stepro 12:50, 6. Dez. 2010 (CET)

Ist gefixt. Ob es hier auch schon "live" ist, weiß ich nicht. Viele Grüße --Saibo (Δ) 15:10, 6. Dez. 2010 (CET)

Ja, ist live, wenn es in der Rubrik steht. Ansonsten würde es unter „Vorschau“ stehen. — Raymond ^Disk. 16:12, 6. Dez. 2010 (CET)

Bestens! Sorry, hatte es verwechselt. Liegt daran, dass ich immer so interessiert die Vorschau lese. :) Viele Grüße --Saibo (Δ) 16:53, 6. Dez. 2010 (CET)