Wikipedia:Usability-Initiative/Softwarefehler/Archiv2010/Juni/24
Link zu http://stats.grok.se/
Seit dem Update funktioniert der Link zu http://stats.grok.se/ (vorhanden ist der Schalter aber noch unter Statistik/andere Tools). Dies war ein recht brauchbares Tool um die Zugriffshäufigkeit auf Lemmata darzustellen. Vielleicht kann Wikipedia dies auch selbst anbieten (so schwer dürfte die Abfrage nicht zu generieren sein). MfG Dr. Huber (nicht signierter Beitrag von Dr. Martin Huber (Diskussion | Beiträge) 13:50, 15. Jun. 2010 (CEST))
- http://stats.grok.se/ funktioniert. Vielleicht ein zeitweiser Aussetzer? --Ska13351 21:06, 15. Jun. 2010 (CEST)
- Hat mit der Usability-Initiative nichts zu tun --Church of emacs D B 12:40, 21. Jun. 2010 (CEST)
- Archivierung dieses Abschnittes wurde gewünscht von: 132.230.1.28 11:16, 28. Jun. 2010 (CEST)
Bild wird nicht richtig dargestellt
Was ist hier faul (s. rechts)? – Firefox 3.6.3 --Frankee 67 07:15, 16. Jun. 2010 (CEST)
- Ich kann am Bild nichts Auffälliges erkennen. Falls es bei dir zu irgendwelchen Fehldarstellungen kommt, würde ich es zunächst auf Wikipedia:Cache schieben und danach darauf, dass FF 3.6.3 (zumindest wie ich ihn das letzte Mal getestet habe) noch ziemlich viele Macken hat. --Schnark 09:39, 16. Jun. 2010 (CEST)
- Archivierung dieses Abschnittes wurde gewünscht von: 132.230.1.28 11:16, 28. Jun. 2010 (CEST)
Verlinken von Bildern mit der Kette nicht möglich
Die Benutzung der Kette zum Bilderverlinken funktioniert nicht. File:Wielrenner Gerber Karstens.JPG|thumb bei mehreren Sprachversionen eingebaut und nun kenne ich dort die Fehlermeldungen... Ich mußte die eckigen Klammern händisch setzen. --Eingangskontrolle 10:12, 16. Jun. 2010 (CEST)
- Wieso willst du unbedingt den Knopf für die Links verwenden um Bilder einzufügen? Der Knopf für die Bilder ist genau rechts daneben, und fügt gleich ein lokalisiertes File: mit ein. Alternativ kannst du natürlich den Dateinamen als Ziel und thumb als Alternativtext angeben oder überall in deinen Einstellungen die Dialoge deaktivieren. --Schnark 11:45, 16. Jun. 2010 (CEST)
- Vielleicht weil das bisher immer eine Verlinkung war? --Eingangskontrolle 20:50, 16. Jun. 2010 (CEST)
- Du kannst einen neuen Link einfügen und beim Seitentitel „Bild:...“ angeben und bei Anzeige im Text dann „thumb“ --Church of emacs D B 12:44, 21. Jun. 2010 (CEST)
- Archivierung dieses Abschnittes wurde gewünscht von: 132.230.1.28 11:16, 28. Jun. 2010 (CEST)
Gilb - Deutsche Bundespost
Sehr geehrte Wikipedia-Mannschaft,
mir ist soeben aufgefallen, dass man mit dem Suchbegriff "Gilb" auf die Wikipedia-Seite der "Deutschen Bundespost" weitergeleitet wird. Das sollte doch nicht so sein, nehme ich an?
Mit freundlichem Gruß Eric W. (nicht signierter Beitrag von Bäre (Diskussion | Beiträge) 01:29, 18. Jun. 2010 (CEST))
- Habe einen Schnelllöschantrag gestellt. --Brunosimonsara 09:15, 18. Jun. 2010 (CEST)
- Archivierung dieses Abschnittes wurde gewünscht von: 132.230.1.28 11:16, 28. Jun. 2010 (CEST)
Versionsgeschichten-Fehler unter Opera
Hallo,
zum zweiten mal bin ich gerade über einen solchen Fehler gestoßen. In einigen Versionsgeschichten geht es, in anderen nicht, beispielsweise hier nicht. Wieso wurde das neue Design nicht auf einen der standardkonformsten Browser abgestimmt? Versionsinformationen:
Version: 10.60 Beta
Build: 3422
Plattform: Win32
Betriebssystem: Windows XP
XHTML+Sprache: Das Plug-in ist nicht geladen
Browser-Identifikation: Opera/9.80 (Windows NT 5.1; U; de) Presto/2.5.29 Version/10.60
Ich hoffe, das hilft. --Z1 23:41, 19. Jun. 2010 (CEST)
- Meines Wissens ist der Code an dieser Stelle nicht skinabhängig. Wie verhält es sich, wenn du
&useskin=monobook
oder&useskin=modern
an die URL anhängst? Gruß --Entlinkt 23:58, 19. Jun. 2010 (CEST)
- Das klappt wunderbar, wie dieser Screen zeigt. Unter Vector fehlen immer noch die selben Inhalte wie oben. Auch modern funktioniert prächtig. --Z1 00:13, 20. Jun. 2010 (CEST)
Reproduzieren kann ich das nicht (ich habe aber auch nur Opera 10.10, nicht 10.60 Beta). Opera hat allerdings einen bekannten Bug, der zu „verschluckten“ Inhalten führen kann (siehe auch hier und – älter – hier, Stichwort „sehr absurder Bug“). Gruß --Entlinkt 00:29, 20. Jun. 2010 (CEST)- Alles falsch, es lag an deiner vector.js. In deiner Benutzer:Z1/vector.css steht übrigens nochmal dasselbe, aber ganz verkehrt (nämlich in Javascript, obwohl es CSS sein sollte). Da sonst nichts drin steht, darf ich die Seite löschen? Gruß --Entlinkt 00:36, 20. Jun. 2010 (CEST)
- Du darfst. Also liegt das an meiner vector.js? --Z1 10:52, 20. Jun. 2010 (CEST)
- Nachtrag: Jetzt, wo die vector.css gelöscht ist, geht es auch wieder. Done. --Z1 10:53, 20. Jun. 2010 (CEST)
- Das klappt wunderbar, wie dieser Screen zeigt. Unter Vector fehlen immer noch die selben Inhalte wie oben. Auch modern funktioniert prächtig. --Z1 00:13, 20. Jun. 2010 (CEST)
- Archivierung dieses Abschnittes wurde gewünscht von: 132.230.1.28 11:16, 28. Jun. 2010 (CEST)
Ich denke, das ist schon eine Problematik. Es wäre gut hier, wenn sich die zwei anderen Teile der Nachricht übers Translatewiki übersetzen ließen, da der Browserstandard inkonsistent ist. --The Evil IP address 19:57, 16. Jun. 2010 (CEST)
- Archivierung dieses Abschnittes wurde gewünscht von: --Schnark 12:16, 5. Jul. 2010 (CEST)
"Dieser Artikel..." überdeckt Sichtungshinweis
Falls auf einer Seite ein Balken mit "Dieser Artikel..." ist, der auf eine Begriffsklärung etc. verweist und es ein Hinweis zu ungesichteten Versionen gibt, so verdeckt der Balken den Kasten mit den Datails zur Sichtung (id="mw-fr-revisiondetails"). --Doj° 19:20, 19. Jun. 2010 (CEST)
- Das liegt meiner Meinung nach an dem
position:relative
in der Vorlage:Bausteindesign und verwandten Vorlagen. Wozu steht das überhaupt drin? --Entlinkt 20:25, 19. Jun. 2010 (CEST) - Workaround aufgenommen. Das Problem betraf alle Skins außer Monobook (und das funktionierte es auch nur aus Zufall). Gruß --Entlinkt 04:45, 21. Jun. 2010 (CEST)
- Archivierung dieses Abschnittes wurde gewünscht von: --Schnark 12:17, 5. Jul. 2010 (CEST)
Skinauswahl wird nur in der DE:WP übernommen
und in allen anderen trotz SUL und zusätzlich entsprechender Auswahl (in wie vielen Sprachen soll ich eigentlich die entsprechenden Sachen lernen?) ignoriert. --Eingangskontrolle 10:15, 16. Jun. 2010 (CEST)
- Leider gibt es noch keine globalen Einstellungen. Das ist kein Fehler der Usability-Initiaven-Software, sondern ein schon lange bestehender Wunsch, den aber noch niemand umgesetzt hat. — Raymond Disk. 12:02, 16. Jun. 2010 (CEST)
Ich benutze Wikipedia hier in der Bibliothek. In letzter Zeit wurde da nichts geändert. Wikipedia (als einziges Programm) läuft sehr langsam. Eine Minute Wartezeit und mehr. Walter (nicht signierter Beitrag von 194.153.96.32 (Diskussion 15:42, 16. Jun. 2010 (CEST))
- Archivierung dieses Abschnittes wurde gewünscht von: Schnark 11:52, 27. Jul. 2010 (CEST)
Keine Umstellung auf Vector in anderen Sprachen
In den anderen Sprachen, die gleichzeitig mit de auf Vector wechselten, erfolgte bei mir kein automatischer Wechsel. Getestet habe ich fr:, it:, ru: und pl:. Das Verhalten ist sowohl in FF 3.6.2 als auch im IE 8 das Gleiche: Beim ersten Aufrufen zeigt sich die Seite in Monobook mit dem Link "Neue Funktionen", nach einem Aufruf eines beliebigen Artikel oder dem Neuladen erscheint zusätzlich der Link "Zurück zur alten Oberfläche", obwohl weiterhin Monobook angezeigt wird. In meinen Einstellungen habe ich eigentlich nichts geändert, lediglich jeweils eine monobook.js angelegt, die damit auch weiterhin ihre Arbeit tut (immerhin eine hilfreiche Folge). Der Wechsel auf Commons und in en erfolgte ohne Probleme, ob der Wechsel in de bei mir funktioniert hätte, weiß ich nicht, da ich Vector hier schon seit Ewigkeiten verwende. --Schnark 10:13, 16. Jun. 2010 (CEST)
- Das ist tatsächlich merkwürdig. An der monobook.js kann es eigentlich nicht liegen, die ist bei mir auf allen Wikis vorhanden und das Problem tritt bei ru auf, bei pl aber nicht… (bei pl wird korrekterweise das Default-Skin angezeigt) --Church of emacs D B 12:49, 21. Jun. 2010 (CEST)
- Nachtrag: Zumindest die neue Werkzeugleiste wurde automatisch aktiviert. (Auf die Schnelle in fr und it überprüft.) --Schnark 11:22, 23. Jun. 2010 (CEST)
Nachdem die Umstellung inzwischen abgeschlossen ist, spielt das hier eigentlich keine Rolle mehr. --Schnark 12:00, 6. Sep. 2010 (CEST)
- Archivierung dieses Abschnittes wurde gewünscht von: --Schnark 12:00, 6. Sep. 2010 (CEST)
„Pfeil-hoch-Helferlein“
Seit gestern ist das „Pfeil-hoch-Helferlein“ links, was ja noch zu akzeptieren wäre. Laut Einstellungsseite: Das „Pfeil-hoch-Helferlein“ fügt zu Kapitelüberschriften einen Rücksprunglink zum Anfang der Seite hinzu. Keine Rede mehr vom Anfang der Seite (mit Reitern und 'Beobachtungsliste' etc.), sondern jetzt führt der Pfeil zur Seitenüberschrift, von dort muss man händisch zum Seitenanfang weiterführen. Was soll denn das? Klare Verschlechterung. --Brunosimonsara 08:31, 17. Jun. 2010 (CEST)
- Diese Änderung geht (teilweise) auf meine Kappe. Passiert ist folgendes: In der deutschen Wikipedia läuft ein Skript namens moveEditsection (2006 in MediaWiki:Monobook.js etabliert und jetzt auch in MediaWiki:Vector.js vorhanden), das nichts anderes tut, als die [Bearbeiten]-Links an Abschnittsüberschriften von rechts außen nach direkt rechts neben den Überschriften zu verschieben. Den Unterschied siehst du, wenn du die Position der [edit]-Links in en:Talk:Main Page mit der Position der [Bearbeiten]-Links in Wikipedia Diskussion:Hauptseite vergleichst (Standard ist die Position, wie sie in der englischen Wikipedia ist).
- Dieses Skript ist problematisch, weil es sehr langsam ist, mit steigender Anzahl von Abschnittsüberschriften auf einer Seite immer langsamer wird und darüber hinaus ziemlich heftig in die Struktur eingreift. (Daran wurde 2006, als es etabliert wurde, nicht gedacht, heute müssen wir damit leben). An dem Skript wurden einige Änderungen vorgenommen, die es schneller machen (wirklich schnell ist es aber trotzdem nicht geworden; die deutsche Wikipedia ist wegen dieses Skripts noch immer messbar langsamer als die englische).
- Leider änderte sich durch die Optimierung des Skripts auch sein Verhalten, so dass ich in MediaWiki:Gadget-Pfeil-hoch.js einige Änderungen vornehmen musste; andernfalls hätte das Gadget überhaupt nicht mehr funktioniert. Bei der Gelegenheit habe ich auch drei Änderungen vorgenommen, die streng genommen nicht unbedingt notwendig waren, aber mir sinnvoll erschienen:
- Die Pfeile sind nun links angeordnet, weil sie so alle untereinander stehen, was bei Bedienelementen m. E. grundsätzlich günstiger als ein „Flattersatz“ ist. Ist man die ältere Version, bei der die Pfeile zwischen Überschrift und [Bearbeiten]-Link standen, gewohnt, muss man sich natürlich erst umgewöhnen, was ärgerlich sein kann.
- Die Schriftgröße der Pfeile richtet sich nun nach der Schriftgröße des Fließtextes, nicht der Überschriften.
- Die Pfeile springen nicht mehr mit der scrollTo-Methode an den Bildschirmanfang, sondern mit #top an den Seitenanfang. Ich halte dies für korrekt: #top ist nicht in allen Skins dasselbe, aber in allen Skins vorhanden und durchaus als „Seitenanfang“ zu bezeichnen. Das vorherige Verhalten war nicht der Seiten-, sondern der Bildschirmanfang.
- Gruß --Entlinkt 22:42, 18. Jun. 2010 (CEST)
- Hallo Entlinkt, mir ist zwar gerade bei der Seite 'Wikipedia:Usability-Initiative/Feedback' aufgefallen, dass das etwas langsam geht, habe mir aber gedacht, das ist, weil sie so lang ist. Dass das Helferlein schuld ist, finde ich nicht sooo tragisch. Aber der Sprung zum "Seitenanfang" und nicht zum "Bildschirmanfang" ist eine Verschlechterung, was will man denn bei der Seitenüberschrift? Gruß! --Brunosimonsara 23:00, 18. Jun. 2010 (CEST)
- Zum Teil ist das auch einfach Ansichtssache. Ich selbst benutze dieses Gadget nicht, sondern sah lediglich, dass es nicht mehr korrekt funktionierte. Erst mal zum technischen Verständnis der ganzen Sache: Vor der Optimierung verschob das Skript in MediaWiki:Vector.js die [Bearbeiten]-Links hinter die Überschriften, nach der Optimierung verschiebt es die Überschriften vor die [Bearbeiten]-Links. Man könnte meinen, das wäre dasselbe, ist es aber nicht mehr, sobald ein Gadget wie MediaWiki:Gadget-Pfeil-hoch.js „dazwischenfunkt“.
- Das musste repariert werden, und bei der Gelegenheit fiel mir auf, dass das Gadget sich auch in anderer Hinsicht unlogisch verhielt. So funktionierte es zum Beispiel in „exotischeren“ Skins wie Klassik oder Modern überhaupt nicht. Die jetzige Version funktioniert in allen Skins (9 Skins werden zurzeit angeboten) und überlässt die Entscheidung, was #top ist, dem jeweiligen Skin:
- Man sieht: In den Skins Klassik und Modern ist #top wirklich ganz oben, in Monobook und Vector über der Hauptüberschrift, also nicht ganz oben, weil noch Navigationselemente darüber stehen. Das ist eine Entscheidung der jeweiligen Skins – ich unterstelle einfach, dass die Skins selbst entscheiden, wo sie ein Element mit der ID "top" unterbringen, dessen einziger Zweck es m. E. ist, Sprunganker für so ein Gadget zu sein.
- Ich kann das Verhalten durchaus wieder zurückstellen, dazu müsste einfach nur ein Teil dieser Änderung rückgängig gemacht werden (aber nicht die ganze Änderung, sonst gehen die Schriftgrößen wieder kaputt). Das kann jeder Admin jederzeit machen. Ich hänge nicht am jetzigen Verhalten, würde aber vor weiteren Änderungen noch weiteres Feedback abwarten. Gruß --Entlinkt 23:20, 18. Jun. 2010 (CEST)
- Die beiden Skins Klassik und Modern haben kein
<a id="top"></a>
. Wenn ich HTML richtig verstanden habe, greifen dann browser-interne Regeln. Das scheint zur Zeit(?) der "echte Seitenanfang"(tm) zu sein, den man auch mit der Taste Pos1 erreicht. Bei den anderen beiden Skins steht der Anker schon ganz weit oben, kurz nach dem body-Tag. Ich vermute, dass die (nachträgliche) Positionierung der Navigationsleiste hier ins Handwerk pfuscht? - Danke Dir auf jeden Fall für die Erläuterungen, was da wie passiert. Für mich ist diese Seite hier jetzt also auch zur Fortbildungseinrichtung geworden ;-) --Ska13351 08:38, 19. Jun. 2010 (CEST)
- Die beiden Skins Klassik und Modern haben kein
- Darüber hatte ich mich auch schon gewundert. Leider funzt bei mir die Pfeil-hoch-Taste nicht. Wenn ich nun sowieso mit der Maus nachhelfen muss, nützt mir das Ganze auch gar nichts mehr. Dann kann ich auch gleich mit der Maus hochscrollen, wenn ich zu den Bearbeiten-/Versionen-usw-Tasten hoch will. Bitte wieder ändern, sonst muss ich mir nen neuen Skin suchen gehen. --Geitost 16:32, 21. Jun. 2010 (CEST)
- PS: Wobei das mit dem Skinwechsel wohl auch nix wird, das gibt dann wieder andere Nachteile. Im Skin Modern wird mir z.B. der Pfeil gar nicht angezeigt, und Klassik gefällt mir anderweitig nicht so, da kann man z.B. die Abschnitte kaum auseinanderhalten. Aber vielleicht gibt es ja auch hier noch ne Änderung und der Pfeil führt wieder nach ganz oben, denn auch zu den eigenen Beiträgen oder der Beo will man ja öfter mal schnell kommen können. *lieb guck* ;-) --Geitost 16:48, 21. Jun. 2010 (CEST)
- PPS: Bei Klassik seh ich wie auch bei Modern auch nirgends nen Pfeil, wenn ich auf deine Links hierdrüber klicke, also hilft da anscheinend auch kein Skinwechsel, dann ist es einfach gar nicht mehr zu benutzen. Das ist dann evtl. wieder ein anderer Bug. --Geitost 16:50, 21. Jun. 2010 (CEST)
- Ska13351 hat recht, #top gibt es nicht in jedem Skin (Klassik und Modern sind gerade zwei von denen, in denen es das nicht gibt, der dritte ist Kölnisch Blau), aber es gibt Browser, die sich so verhalten, als gäbe es das immer und als wäre es ganz oben, wenn es das nicht gibt. Du verwendest anscheinend einen, der das – ganz zu Recht – nicht tut. Auf so undokumentiertes Browserverhalten sollte man nichts bauen, ich hab’s deshalb zurückgestellt.
- Und wie sieht es mit der Position aus, links oder rechts der Überschrift? Wenn man die Pfeile in die Überschriften packt, wäre beides möglich. (In die Überschriften gehören sie zwar streng genommen nicht, aber es macht visuell keinen Unterschied.) Gruß --Entlinkt 19:13, 21. Jun. 2010 (CEST)
- Archivierung dieses Abschnittes wurde gewünscht von: --Schnark 11:37, 7. Sep. 2010 (CEST)
Sonderzeichen in "Datei hochladen"
Auf der Spezialseite "Datei hochladen" lassen sich bei mir (XP, Firefox 3.6.3) in das Editierfenster zur Dateibeschreibung keine Sonderzeichen aus der darunter befindlichen Auswahl einfügen. Bei einem Klick auf ein Zeichen springt die Seitenansicht auf den oberen Seitenrand und der Cursor verschwindet aus dem Editierfenster. - --Eweht 01:06, 19. Jun. 2010 (CEST)
- Kann ich bestätigen, Firefox bemängelt in edit.js die Zeile
( currentFocused.nodeName.toLowerCase() == 'iframe' || currentFocused.id == 'wpTextbox1' ) ) {
- mit "currentFocused is null". --Schnark 09:52, 19. Jun. 2010 (CEST)
- Archivierung dieses Abschnittes wurde gewünscht von: --Schnark 09:25, 10. Jan. 2011 (CET)