Wikipedia:Usability-Initiative/Softwarefehler/Archiv2010/Juli/28
Sichtungsoption bei Seitenneuanlage
Beim Anlegen einer neuen Seite wird (sowohl in Monobook als auch in Vector) unten die Option „Sichte die komplette Seite“ angeboten, die normalerweise beim Bearbeiten von Seiten mit ungesichteten Versionen erscheint. Das Nichtsetzen des Häkchens hat aber keinen Einfluss, die Seite wird trotzdem „automatisch gesichtet“. --Katimpe 20:02, 13. Jul. 2010 (CEST)
- Da dies nichts mit Vector zu tuen hat, habe ich es mal nach Wikipedia Diskussion:Gesichtete Versionen#Sichtungsoption bei Seitenneuanlage übertragen. Der Umherirrende 21:47, 14. Jul. 2010 (CEST)
- Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 21:47, 14. Jul. 2010 (CEST)
seltsame Vorschläge der Suchbox in Verbindung mit Umlauten
- Wenn man "Jaml" eingibt (um nach "Jamlitz" zu suchen),
erscheinen - je nach Lust und Laune des Programmes -
- - entweder
- Jamlitz
- Jamlitz-Klein Düben (obwohl das Jämlitz ist)
- Jamlitz (obwohl das Jämlitz ist)
- usw.
- - oder
- Jämlitz (obwohl das Jamlitz ist)
- Jämlitz-Klein Düben
- Jämlitz
- Im fettgedruckten Wortteil wird also entweder alles mit "a" oder alles mit "ä" dargestellt. Wenn man auf das erste in der Suchbox angebotene Wort klickt (ganz gleich wie es dort geschrieben ist), wird "Jamlitz" geholt. Wenn man auf das dritte in der Suchbox angebotene Wort klickt (ganz gleich wie es dort geschrieben ist), wird "Jämlitz" geholt. (Das bei der Eingabe von "Jaml" nicht fette "Düben" wird immer richtig mit "ü" dargestellt!).
Bei "Volltextsuche" ist auch nervig, dass sowohl alles mit "a" als auch alles mit "ä" gelistet wird. Gruß -- Dr.cueppers - Disk. 11:06, 12. Jul. 2010 (CEST)
- Es ist das selbe Problem wie eins obendrüber. --Schnark 11:14, 12. Jul. 2010 (CEST)
- Archivierung dieses Abschnittes wurde gewünscht von: Schnark 10:03, 26. Jul. 2010 (CEST)
Diff zur abgespeicherten Version wird in der Vorschau immer (?) mitgeliefert
Es scheint so zu sein, dass die Vorschau auch den Diff zur Vorgängerversion mitliefert und dieser dann per JavaScript am Client ausgeblendet wird. Da es ohnehin Beschwerden über die Performance von Vector gibt, hier wäre ein Ansatz, Bandbreite zu sparen und damit die Performance zu verbessern: der diff sollte nur geliefert werden, wenn angefordert. (ev. hängt das mit meiner Einstellung: Zeige beim Bearbeiten auch den Unterschied zur letzten stabilen Version im Versionsvergleich zusammen.) lg --Herzi Pinki 12:11, 17. Jul. 2010 (CEST)
- Der Diff wird in allen Skins so angezeigt und befindet sich in einem div mit der ID
mw-fr-stablediff
. Das kann nur in der FlaggedRevs-Erweiterung geändert werden. Die Skins wissen nicht mal, dass es diese Sache überhaupt gibt. Gruß --Entlinkt 18:56, 17. Jul. 2010 (CEST) - PS: Sinn der Sache könnte sein, dass die Einstellung Zeige beim Bearbeiten auch den Unterschied zur letzten stabilen Version im Versionsvergleich auch bei deaktiviertem JavaScript noch funktioniert. --Entlinkt 21:43, 17. Jul. 2010 (CEST)
- Archivierung dieses Abschnittes wurde gewünscht von: --Schnark 12:11, 6. Sep. 2010 (CEST)
Vector Skin lädt nicht vollständig über mobiles Internet?
Hallo! Mit der Einführung des neuen Designs tritt anscheinend folgendes Problem auf: Bei einem UMTS-Internetzugang über Handy an Notebook (OS Vista/Browser FF, auch in IE) werden eine Reihe an Dateien vom Server bits.wikimedia.org nicht mit übertragen. Beim Neuladen (STRG + F5) , endet das Laden nicht, beim normalen Refresh versucht FF sie jedoch aus dem Browser Cache zu ziehen (304 Unmodified).
Betroffen sind anscheinend die jquery & ajax libs, mwsuggest.js & vector.combined.min.js.
Die Skin ist dadurch unvollständig und die Seite faktisch kaum nutzbar. Das Problem ist seit Tagen persistent, Cache löschen, FF-Plugins deaktivieren etc. bringt keine Veränderung. Das Problem tritt auch mit dem IE auf. Ich verstehe das Problem überhaupt nicht.
Gibt es dazu schon irgendwelche Infos?
Wo kann der Bottleneck sein?
--Uweka 12:13, 13. Jul. 2010 (CEST)
- Verwendet dein Mobilfunkprovider einen UMTS-Proxy? Wenn ja, hast du schonmal probiert, den abzustellen (providerabhängig mit speziellen Tools, oder generell evt. mit diversen Konfigurationen oder Browserplugins machbar - Google ist dein Freund)? Mindestens Vodafone greift da ziemlich heftig in praktisch alles ein, was übertragen wird, und verhunzt dabei natürlich mehr als einem lieb sein kann. Aber auch die anderen Provider setzen wohl Proxys ein. --YMS 15:11, 13. Jul. 2010 (CEST)
Falls doch noch eine Antwort auf die Rückfrage kommt, einfach den erledigt-Baustein entfernen. --Schnark 11:28, 13. Sep. 2010 (CEST)
- Archivierung dieses Abschnittes wurde gewünscht von: --Schnark 11:28, 13. Sep. 2010 (CEST)
Probleme beim Editieren unter Vector
...habe ich in der Vorschaufunktion erfahren: einiges funktioniert nicht so wie unter Monobook; z.B. wird bei Tabellen die Sortierfunktion weder angezeigt noch ausgeführt (vgl. [1]); des Weiteren funktioneieren die Wikipedia:Helferlein/Navigation-Popups nicht, die ich immer verwende, um zu prüfen, ob ich auf eine Weiterleitung verlinke oder direkt auf den Artikel. Und auch das BKS-Helferlein funzt nicht. --Carbenium 17:28, 13. Jul. 2010 (CEST)
- Kann ich bei mir alles drei nicht nachvollziehen. Welchen Browser verwendest du, was läuft da sonst noch für Scriptzeug, etc.? Außerdem: Wenn du Popups wirklich nur für die Redirectüberprüfung nutzt, ist das ein wenig Overkill. Da gäbe es die CSS-Variante, oder, wenn auch das Weiterleitungsziel angezeigt werden soll, zumindest schlankere Scripts. Aber grundsätzlich soll dir's natürlich unbenommen sein, Popups einzusetzen, auch mit Vector. --YMS 18:22, 13. Jul. 2010 (CEST)
- FF 3.5.10 mit ca 40 aktiven Addons – falls Du sowas mit "Script-Zeug" meinst. NoScript und CS Lite sind auch dabei, aber wikipedia.org ist bei beiden komplett gewhitelistet. Monobook funktioniert mit den selben Settings ohne Probleme. Natürlich verwende ich die Popups auch beim Artikellesen, beim Bearbeiten von Letzte Änderungen, der Beobachtungsliste und und und. Aber es ist halt an der Stelle schon ein Lästigkeitsfaktor, wenn ich gerade beim Editieren wieder anfangen muss, die einzelnen Seiten separat aufzurufen. --Carbenium 18:51, 13. Jul. 2010 (CEST)
- Also bits.wikimedia.org sollte auf alle Fälle auch auf deine Whitelist, wobei ich mir nicht vorstellen kann, dass Monobook funktioniert, wenn Skripts von dort blockiert werden. --Schnark 09:47, 14. Jul. 2010 (CEST)
- *.wikimedia.org ist natürlich auch gewhitelistet, genauso wie viele andere Schwesterprojekte... ;-) hat bits.wikimedia.org eigentlich eine ähnliche Aufgabe wie der Toolserver? --Carbenium 13:14, 14. Jul. 2010 (CEST)
- Also bits.wikimedia.org sollte auf alle Fälle auch auf deine Whitelist, wobei ich mir nicht vorstellen kann, dass Monobook funktioniert, wenn Skripts von dort blockiert werden. --Schnark 09:47, 14. Jul. 2010 (CEST)
- FF 3.5.10 mit ca 40 aktiven Addons – falls Du sowas mit "Script-Zeug" meinst. NoScript und CS Lite sind auch dabei, aber wikipedia.org ist bei beiden komplett gewhitelistet. Monobook funktioniert mit den selben Settings ohne Probleme. Natürlich verwende ich die Popups auch beim Artikellesen, beim Bearbeiten von Letzte Änderungen, der Beobachtungsliste und und und. Aber es ist halt an der Stelle schon ein Lästigkeitsfaktor, wenn ich gerade beim Editieren wieder anfangen muss, die einzelnen Seiten separat aufzurufen. --Carbenium 18:51, 13. Jul. 2010 (CEST)
- Ich würde bits.wikimedia.org eher mit den Commons vergleichen, als mit dem Toolserver. Um den Fehler einzugrenzen, solltest du mal ausprobieren, ob alles funktioniert, wenn du ohne Addons arbeitest, also Firefox im abgesicherten Modus starten. Wenn dort kein Problem auftritt, müsstest du nur noch das Addon finden, das für das Problem verantwortlich ist (binäre Suche geht wohl am schnellsten). --Schnark 09:56, 17. Jul. 2010 (CEST)
Falls doch noch eine Antwort auf die Rückfrage kommt, einfach den erledigt-Baustein entfernen. --Schnark 11:28, 13. Sep. 2010 (CEST)
- Archivierung dieses Abschnittes wurde gewünscht von: --Schnark 11:28, 13. Sep. 2010 (CEST)