Dies ist eine alte Version dieser Seite, zuletzt bearbeitet am 31. Oktober 2011 um 23:06 Uhr durch Knochen(Diskussion | Beiträge)(→Lemmanamen). Sie kann sich erheblich von der aktuellen Version unterscheiden.
Auf dieser Seite werden Abschnitte automatisch archiviert, deren jüngster Beitrag mehr als 4 Tage zurückliegt und die mindestens einen signierten Beitrag enthalten.
Info: Bei MediaWiki, der Software der Wikipedia, wurde eine Aktualisierung auf die Version 1.18 durchgeführt. Deshalb kann es derzeit zu Änderungen der Anzeige kommen, insbesondere auf der erweiterten Beobachtungsliste, den Kategorien und im Monobook-Skin. Derartige Probleme können hier auf der Seite oder auf der vorgesehenen Meta-Seite gemeldet werden. Auch bereits bekannte Bugs werden verlinkt. Bei Problemen mit benutzerspezifischen Einstellungen hilft die Skin-Werkstatt weiter. Blogmeldung
Aktuell läuft hier diese Softwareversion: 1.44.0-wmf.24 (7a570e7) (automatisch aktualisierte Vorlage).
Bitte in allen Unterabschnitten keine erledigt-Vorlage verwenden, sonst wird alles zu MediaWiki 1.18 auf einmal archiviert. --Saibo (Δ) 20:10, 10. Okt. 2011 (CEST)[Beantworten]
MW118: Disk 0
Server-Admin-Log (Zeiten in UTC) mit den letzten Änderungen. Vor 20 Minuten wurde Commons auf 1.18 umgestellt. Außerdem sind umgestellt: enwiki, frwiki, plwiki.
Wir kommen wohl in diesem Schub doch noch nicht, wenn ich die Aussagen im Chat richtig verstehe. Ich schätze dann in 12 Stunden oder so. --Saibo (Δ) 06:06, 5. Okt. 2011 (CEST)[Beantworten]
Einen Vorgeschmack bzw. Problemlösungen auf die/der Probleme morgen (oder so) kann man in den beiden Interwikis oben bekommen. --Saibo (Δ) 19:31, 5. Okt. 2011 (CEST)[Beantworten]
Ich wollte gerade fragen, warum mein Monobook-Skin in der en-WP so merkwürdig aussieht. Doppelte Zeilenabstände bei den Kategorien, ein nicht mehr ordnungsgemäß funktionierendes Suchfeld - super! Sagt mal, muss denn jedes Update ein qualitatives Downgrade nach sich ziehen? Ich kapiere das ums Verrecken nicht, warum man ein funktionierendes System sabotieren muss. Bedient, --ScooterBackstage21:51, 5. Okt. 2011 (CEST)[Beantworten]
Größte Verbesserung: Die automatische Vergabe des Passiver-Sichter-Status wird jetzt im Rechtelogbuch vermerkt. Größte Verschlechterung: Die Benutzerbeiträge sind nicht mehr nach Namensraum sortierbar (was die Arbeit erheblich erschweren wird...). Das lässt sich aber wohl mit der Installation des Gadgets meta:MediaWiki:Gadget-rightsfilter.js beheben. XenonX3 - (☎:✉) 01:26, 6. Okt. 2011 (CEST)[Beantworten]
Hat der Kasten mit der Einleitung nur bei mir so einen schwarzen Trauerrand? das war mir vorhin noch nicht aufgefallen... Außerdem, da ich gerade einen BK mit XenonX3 hatte, fällt auf, dass das Fenster "Dein Text" nun grau hinterlegt ist. Grüße, Grand-Duc01:29, 6. Okt. 2011 (CEST)[Beantworten]
Den Trauerrand hab ich auch.
Viel schlimmer ist aber, dass (vermutlich) alle Infoboxen nicht mehr rechts stehen, sondern über der Einleitung (Hochschule, Verein und Unternehmen angesehen). --Geri, ✉01:51, 6. Okt. 2011 (CEST)[Beantworten]
Aha! Abgemeldet funkt's wie gehabt. Ein Helferlein oder etwas in der monobook.js nicht kompatibel? Und steht links meintest Du wohl, nicht? (so irritiert davon? ;-) --Geri, ✉02:02, 6. Okt. 2011 (CEST)[Beantworten]
Angeblich soll sich die Kategorienanzeige nicht ändern. Da habe ich leider einen ganz anderen Eindruck. Und bei den Bearbeitungsknöpfen gibt es nur eine reduzierte Anzeige. --Enzian4402:32, 6. Okt. 2011 (CEST)[Beantworten]
Vielleicht wäre es sinnvoll, wenn wir thematisch gruppierte Unterabschnitte erstellen. ;) Vor allem für die mehr oder weniger echten Bugmeldungen (siehe die Seite in Commons). Viele Grüße --Saibo (Δ) 02:41, 6. Okt. 2011 (CEST)[Beantworten]
MW118: Passiver-Sichter-Status (autoreview) nun als separates Benutzerrecht
Laut WP:NEU: "(Softwareneuheit) Das autoreview-Recht kann nun auch ohne kurzzeitige Benutzersperre entfernt werden". Dann müsste doch doch z.B. bei Spezial:Benutzerrechte/Grimba (kein Testaccount!) eigentlich gehen.. Die Checkbox ist angehakt, aber ausgegraut. Komisch. Falsch verstanden? --Saibo (Δ) 02:16, 6. Okt. 2011 (CEST)[Beantworten]
Wie bekommt man sie wieder platzsparender hin? CSS müsste wohl geändert werden. --Saibo (Δ) 04:34, 6. Okt. 2011 (CEST) Ah, die en.Wikipedianer haben schon teilweise etwas herausgefunden ... (nun hier oberhalb verlinkt) --Saibo (Δ) 05:45, 6. Okt. 2011 (CEST)[Beantworten]
Ich frage mich zwar ganz ernsthaft, wie man so eine Syntax auf der Stelle herzaubert (und was wir hier täten, wenn es nicht Leute gäbe, die so etwas wissen), aber davon ab danke ich dafür herzlich. Wenigstens ein kleiner Schritt zurück zur Normalität und weg von "wie gewollt und nicht gekonnt". --ScooterBackstage10:49, 6. Okt. 2011 (CEST)[Beantworten]
Scooter, ich pflichte dir voll und ganz bei. Welcher bürokratische Hohlkopf ist auf die Idee gekommen so etwas abschreckendes auf den Weg zu bringen. @Formafix: Funktioniert das auch mit Monobook? Gruß & Dank --Laibwächter14:39, 6. Okt. 2011 (CEST)[Beantworten]
Danke - funktioniert (in Monobook, Firefox 3.6). Wenn es allgemein eher gewünscht ist, dann sollten wir es vielleicht in die allgemeine commons.css schreiben. Sonst müssen die Technik-DAUs leiden. --Saibo (Δ) 18:26, 6. Okt. 2011 (CEST)[Beantworten]
Wenns bloß um die Optik geht, würde ich aber #catlinks li { padding:0 .3em; border-color:black; } #catlinks li:first-child { padding-left:0; } empfehlen. Schließlich habe ich selbst dafür gestimmt, den senkrechten Strich aus der Formatierung zu verbannen. Grau + größere Abstände passen halt zu Vector, halte ich für nachvollziehbar (und Monobook bleibt trotzdem besser). -- ✓Bergi00:28, 7. Okt. 2011 (CEST)[Beantworten]
Ich würde es für Monobook so lassen, wie es bisher war (können wir das nicht in eine allgemeine monobook.css schreiben?). Monobook-user wollen keine Verschlechterungänderung, oder? ;) (bin natürlich selbst einer) Wir würde ein Mittelding zwischen Fomafix und Bergi gefallen - so ein etwas erhöhter Zeilenabstand ist schon nicht verkehrt. Bergi, was ist denn an dem senkrechten Strich dir nicht gefällig? ;) --Saibo (Δ) 02:43, 7. Okt. 2011 (CEST)[Beantworten]
Das gewünschte Ergebnis ist ein Rahmenelement und kein Schriftzeichen (wie beispielsweise eine automatische Nummerierung per counter()). Daher würde ich auch Rahmensyntax bevorzugen. Zudem gibt es manche Browser, in denen per content: eingefügter Inhalt selektierbar ist, hier ist das Unsinn. Einziger Nach- (oder Vor-)teil ist, dass der Strich nicht nur Buchstaben-, sondern Element- (also Zeilen-)höhe hat.
Der größere Abstand von .7em im Vergleich zum bisherigen Leerzeichen (etwa 0.25em) ist auf alle Fälle nichts, ich würde fast einen Bugantrag stellen anstatt das lokal zu lösen. -- ✓Bergi16:50, 7. Okt. 2011 (CEST)[Beantworten]
MW118: Animation in der erweiterten Version der RC/Beo
Noch was Tolles: Wenn man die erweiterte Version der letzten Änderungen aktiviert hat gibt es jetzt eine zeitverschwendende Animation beim Öffnen und Schließen der einzelnen Punkte. Wer sich sowas ausdenkt... --StG1990Disk.04:22, 6. Okt. 2011 (CEST)[Beantworten]
Mit dem Wikipedia-Update sind eine Menge Dinge aufgetreten, die die Freude mit dem Umgang von Wikipedia vermissen lassen. Mit der interaktiven Beobachtungsliste (ein- und ausklappen) hat die Liste eine enorme Aufbauzeit, da jeder einzelne Beitrag einzeln eingeklappt wird. Das kann dauern. Einfach nur furchtbar! Ah ja, als Browser dient das neueste Modell von Opera. Gruß -- Matthias à titre de «M 93» + «disc»15:09, 10. Okt. 2011 (CEST)[Beantworten]
Interessant :-) Ich habe mit Opera keine Klappanimation, mit Chrome und IE beim Auf- und Einklappen und mit Firefox nur beim Einklappen.... Jedenfalls eine lästige Verzögerung. Gruß, adornix(disk)20:30, 10. Okt. 2011 (CEST)[Beantworten]
Den langen Aufbau kann ich unter Windows 7 mit der neuesten Firefox-Version nicht finden. Mit Opera als Browser ist der Aufbau der Beobachtungsliste ähnlich lästig wie mit Firefox und Opera auf XP. -- Matthias à titre de «M 93» + «disc»16:30, 12. Okt. 2011 (CEST)[Beantworten]
Fürchterliche Erfindung. Erschwert bei mir die Arbeit mit der Beobachtungsliste sehr, und der optische Firlefanz ist doch eh für die Katz. Da sollte mindestens eine Anklick-Option zum Ausschalten in die Accounteinstellungen wandern...--Athanasian15:23, 20. Okt. 2011 (CEST)[Beantworten]
Die neuen Klappfunktionen scheinen im Opera grundsätzlich zu spinnen. Ich habe Bug #31832 gemeldet und ich denke, das einige der hier geschilderten Phänomene die selbe Ursache haben. --TMg23:24, 20. Okt. 2011 (CEST)[Beantworten]
Die erweiterte Diff-Ansicht von WikEd ist nicht mehr verfügbar. Außerdem lassen sich Links in den Diffs nicht mehr anklicken, keine Ahnung ob das auch ein Feature von WikEd ist, glaube aber schon. Außerdem ist der Hinweis, das man andere darauf hinweisen kann, das man etwas sichtet grottig übersetzt. --StG1990Disk.08:29, 6. Okt. 2011 (CEST)[Beantworten]
Für diejenigen, die nicht darauf warten wollen, dass Cacycle das korrigiert, mein Skript funktioniert weiterhin problemlos. Einfachste Methode es einzubinden ist ein
Sobald Cacycles Skript wieder funktioniert, hast du dann halt zwei Skripte, die im Wesentlichen das gleiche tun; nicht schädlich, sondern allerhöchstens verwirrend. Andererseits kannst du dann ausprobieren, welches dir besser gefällt (meines ist, soweit ich weiß, etwas langsamer, außerdem macht es die Wikilinks im Diff nicht klickbar [was ich für einen Vorteil meines Skripts halte, aber andere sehen das anders]). --Schnark10:18, 6. Okt. 2011 (CEST)[Beantworten]
Die Langform <math>\dot{\vec{B}}</math> funktioniert: . Warum wird denn bitte da was geändert, ich dachte der ganze Mathe-Teil von Mediawiki wäre auf "won't fix" gestellt? Weiß jemand, was denn in dem Bereich geändert wurde jetzt? --engeltr11:31, 6. Okt. 2011 (CEST)[Beantworten]
Es gibt in der MW118 nicht nur simple parser-Fehler mit wilden roten Text die gleich ins Auge springen, sondern auch subtilere Math-Layoutfehler, z.B.: (The arrow and the dot is not over the letter B. After remove of the "\text{rot}" at the beginning, the parser will fail. A "\dot{\vec B})" will fix the output. Diese latex-Störeffekte treten auch auf en-wp und am test.wikipedia.org auf.--wdwd00:30, 7. Okt. 2011 (CEST)[Beantworten]
Soweit ich das sehe, ist das kein Bug, sondern ein Übergang zu mehr LaTeX-konformem Verhalten. Wenn zwei Makros aufeinander folgen, dann sollte das Argument des äußeren geklammert werden, da sonst das zweite Makro, d.h. der Makrobefehl selbst, als Argument des ersten genommen wird, mit katastrophalen Folgen.--LutzL13:42, 9. Okt. 2011 (CEST)[Beantworten]
Latex interpretiert seit jeher 2 aufeinander folgende Befehle als einen, der auf das nächste Objekt angewendet wird. Klammern sind da nicht zwingend. --engeltr22:43, 9. Okt. 2011 (CEST)[Beantworten]
MW1.18: Benutzerbeiträge sind nicht mehr nach Namensraum sortierbar
das ist ja wohl völlig §$%& - gibt's schon Abhilfen (obig angesprochenes Gadget-rightsfilter.js funktioniert jedenfalls bei mir noch nicht wie zunächst von mir gedacht, wohl aber so)? ca$e09:11, 6. Okt. 2011 (CEST)[Beantworten]
Ich glaube, besagtes Gadget muss man mal kopieren und für "Namensraum-Filterung" optimieren. Kann ja eigentlich so schwer nicht sein. Ist nur mal wieder.... wenig sinnvoll. *seufz* Besonders blöd: Der fragt die letzten <x> Änderungen ab und filtert darin. GANZ toll. Ich will die letzten 50 Änderungen eines Namensraum, nicht "aus den letzten 50 Änderungen was raussuchen". Okay, das schreit eigentlich nach API-Nutzung (wo der Filter im übrigen noch gut funktioniert....) --Guandalug09:30, 6. Okt. 2011 (CEST)[Beantworten]
Das war eine Änderung "weil der Filter zu ineffizient ist auf der Datenbank". Das hat mit den anderen Updates nichts zu tun, wurde auch schon entsprechend angemeckert, aber ich fürchte, das bleibt so. Dann muss man das halt via Toolserver machen...... --Guandalug09:50, 6. Okt. 2011 (CEST)[Beantworten]
Ach ja; der gute alte, ewig langsame Toolserver...
Würd' ich unterschreiben. Ich halte auch nix von der Toolserver-Lösung (bin mir nicht mal sicher, ob das erlaubt wäre, wo doch die Wiki-Software diesen Filter nicht mehr hat.....), aber ich sag mal so: Wenn ich wissen will, wann ich selbst im MediaWiki-Namensraum was geändert habe, dann will ich nicht X Seiten abklappern. Da ist mal wieder was repariert worden, was gar nicht wirklich kaputt war, scheint mir. --Guandalug12:28, 6. Okt. 2011 (CEST)[Beantworten]
Bei Benutzung der Vorschau-Funktion kommt es jetzt oft zu Seitenladefehlern (bei IE8), d. h. die Verbindung zum Internet wird getrennt und dabei geht höchst ärgerlicherweise die letzte Bearbeitung unrettbar verloren. Hier tropft der verschüttete Kaffee aus der Tastatur, einen weiteren Kommentar erspare ich mir mal lieber... ;-( --Jocian09:57, 6. Okt. 2011 (CEST)[Beantworten]
Hat schon jemand angemerkt, dass (zumindest unter Monobook) die Navileisten komplett zerschossen sind? Nein? Na, dann mache ich's mal. Ich werde immer wütender über diesen Mist... --ScooterBackstage10:12, 6. Okt. 2011 (CEST)[Beantworten]
Hatte ich mir fast schon gedacht. Ein Schelm, wer Böses dabei denkt - beispielsweise, dass man so dazu gedrängt werden soll, den furchtbaren Vector-Skin zu übernehmen. Ich kriege langsam Ätzpickel... Hoffentlich setzt sich hier mal jemand bitte auch für jene Benutzer ein, die weiter mit Monobook arbeiten wollen! --ScooterBackstage10:33, 6. Okt. 2011 (CEST)[Beantworten]
Wo ist bitte die Sonderzeichenleiste (geschützte Leerzeichen, Gedankenstriche etc.) geblieben? Wie soll man das eintragen? Aus dem Gedächtnis? Mit dauerndem Kopieren aus anderen Artikeln? Nicht zu fassen... --ScooterBackstage10:22, 6. Okt. 2011 (CEST)[Beantworten]
Danke fürs Nachschauen und den Hinweis, aber zumindest dabei hat das jetzt nichts gebracht. Leiste ist nach wie vor nicht da. Vermutlich auch so ein Fehler, der mysteriöserweise bei Vector nicht auftritt... --ScooterBackstage10:39, 6. Okt. 2011 (CEST)[Beantworten]
Das Problem liegt nicht bei dir Scooter; auf Commons sind die Sonderzeichenlisten auch nicht da wo sie sein sollten, auch wenn sie zumindest unter Vector zumindest da sind. Ich weiß nicht, mir kommt es vor, als wäre jedes neue Update chaotischer als das vorherige. Auf EN hat man übrigens viel mehr Bugs und Probleme als wir hier. Entweder sind wir nicht so fix im Finden oder in EN reizen die das System stärker aus. ;-) --Matthiasb(CallMyCenter)10:52, 6. Okt. 2011 (CEST)[Beantworten]
Das ist genau das, was ich (weiter unten) sage: Ich hasse überflüssige Updates. Warum meint jemand, in einem funktionierenden System zwingend herumfummeln zu müssen? Diesen Leuten gehört mehrfach heftig vors Schienbein getreten für ihre Herumspielerei. Sind da Zehnjährige am Werk, die einfach mal ein bisschen Spaß haben wollen? --ScooterBackstage10:56, 6. Okt. 2011 (CEST)[Beantworten]
haben die braven programmierer offenkundig gefixed
Ich mach’s mal wieder auf: benutze als Skin Modern (ja, ich weiß exotisch; aber zum Bearbeiten finde ich ihn ganz angenehm) und die Edittools fehlen. Ich bilde mir ein, dass das seit der Umstellung auf 1.18 so ist. Zuerst dachte ich, ich gewöhne mich dran, aber mittlerweile nervt’s. Ein generelles Problem oder liegt es an meiner zusammenkopierten .js/.css? Unter Vector habe ich keine Probleme. --Alex00:24, 9. Okt. 2011 (CEST)[Beantworten]
Was meinst du mit Edittools: Editbuttons, erweiterte Editbuttons (Gadget), Sonderzeichenleiste? Bei mir funktioniert sämtliches auch unter modern-Skin. Daher: Browser, Betriebssystem? -- ✓Bergi21:48, 10. Okt. 2011 (CEST)[Beantworten]
Ich meine die Bearbeitungsleiste unterhalb des Editierfensters a.k.a. Sonderzeichenleiste. (Ich vermute, das ist das hier.) Firefox 7 auf Linux. Wie gesagt, ich habe sowohl in meiner .js als auch .css rumgespielt ohne genau zu wissen was ich tue und unter Vector habe ich das Problem nicht. --Alex23:20, 10. Okt. 2011 (CEST)[Beantworten]
Habe jetzt noch mal ein wenig rumgesucht. Vermutlich hat es was mit MediaWiki:Onlyifediting.js zu tun. Auf jeden Fall sehe ich jetzt unterhalb des Bearbeitungsfensters keine Sonderzeichen etc., die ich dann einfach in den Text klicken kann. (Die Leiste oben funktioniert.) --Alex14:14, 28. Okt. 2011 (CEST)[Beantworten]
Meine einzige bisherige Sperre von 2006 über 1 Stunde ist jetzt zu einer Sperre bis zum datum von heute mutiert. Anderen geht es wohl genauso (siehe Fossa).--♥ KarlV15:24, 6. Okt. 2011 (CEST)[Beantworten]
Das sieht mir ganz nach einer Parameterverschiebung aus.... Seltsam. Im Code hab' ich jetzt auf die Schnelle nix gefunden, aber das heisst wenig. --Guandalug16:47, 6. Okt. 2011 (CEST)[Beantworten]
Das sind 2 unterschiedliche Dinge. Das Recht "passiver Sichter" wird nur an leute verliehen, die (unter anderem) nie gesperrt wurden. Hier geht es um die Falsche Anzeige der Dauer der Sperre. --Guandalug17:32, 6. Okt. 2011 (CEST)[Beantworten]
auch contribsrange.js bzw. das CIDR-Helferlein ("Zeigt die Beiträge von 16er und 24–32er CIDR-Ranges und Wildcardbenutzernamen wie „Splark*“ über API an.") scheint nicht mehr zu funktionieren? ca$e10:38, 6. Okt. 2011 (CEST)[Beantworten]
Was dann wohl die Verschwörungstheorien abhaken sollte.
Könnte bitte ein Admin in MediaWiki:Vector.js das float:none; noch mit einem !important unterstreichen oder alternativ die Spezifizität das Selektors noch durch ein #bodyContent erhöhen? Das sollte eigentlich reichen, um das Problem zu beheben. --Schnark11:10, 6. Okt. 2011 (CEST)[Beantworten]
"Unter Monobook sind sie bei den Überschriften." Wer behauptet das? Bei mir (Monobook) sind sie ganz rechts außen. Naja, man muss wohl, wie ich irgendwo anders hier gerade gelesen habe, damit leben, mit Ausschussware arbeiten zu müssen, wenn man sich nicht dazu drängen lassen will, einen unerwünschten Skin zu adaptieren. So ist der Lauf der Welt! --ScooterBackstage11:23, 6. Okt. 2011 (CEST)[Beantworten]
Wer das behauptet hat, weiß ich nicht, du kannst natürlich in der Versionsgeschichte suchen und die unsigned-Vorlage hinzufügen, da ich es aber gerade selber ausprobiert habe, sage ich das auch. Unter Monobook mit ansonsten Standard-Einstellungen sind die Bearbeiten-Links weiterhin direkt rechts neben den Überschriften. --Schnark11:34, 6. Okt. 2011 (CEST)[Beantworten]
Das war ich. Scooter, hast du mal versucht, in den Einstellungen/Helfelein "Bearbeiten-Links Rechts verschiebt die [Bearbeiten]-Buttons vom Fensterrand direkt rechts neben die jeweiligen Überschriften." zu aktivieren? (Bei mir isses nicht aktiviert. Falls es bei dir aktiviert ist, dann versuche es mal zu deaktivieren.) --Matthiasb(CallMyCenter)11:52, 6. Okt. 2011 (CEST)[Beantworten]
Bei mir (aktiviertes Helferlein) sind die Buttons im ANR an der Überschrift (Ausnahme: Die Einleitung), in allen anderen NR sind sie ganz rechts.--Nothere17:42, 6. Okt. 2011 (CEST)[Beantworten]
Es war angekündigt, dass Spezial:Präfixindex bei Einbindung in eine Seite alle Seiten anzeigt. Das ist nicht der Fall. Außerdem sind die Spalten jetzt am linken Bildrand gedrängt anstatt die gesamte Bildschirmbreite einzunehmen. SteMicha11:32, 6. Okt. 2011 (CEST)[Beantworten]
Doch, es wird jetzt so etwas wie Spezial:Alle Seiten angezeigt (bzw. es wird ein leerer String als Präfix verwendet). Wie im verlinkten Bugreport beschrieben, wurde zuvor eine input-Box angezeigt wenn kein Präfix angegeben war. Mal im Ernst: Du hättest doch wohl nicht wirklich erwartet, alle 8.264.519 Seiten aufgelistet zu bekommen? Wenn du meinst es sei nötig, dann formulier den Eintrag auf WP:NEU um. -- ✓Bergi21:33, 10. Okt. 2011 (CEST)[Beantworten]
Seiten ausklappen
Die neue Funktion, bei der sich mit
<div class="mw-collapsible mw-collapsed"> blabla </div> ganze Seiten ein- und ausklappen lassen können, rendert zumindest bei Firefox sehr langsam. Es kommt zu unschönen Rucklern. SteMicha12:07, 6. Okt. 2011 (CEST)[Beantworten]
Warum braucht es den klappbaren Murks überhaupt. Worin liegt der Sinn ganze Seiten aus- oder einzuklappen. Ist das die Bunga-Bunga-Funktion? Können wir nicht die class lokal aus der CSS löschen, damit sich das gar nicht erst verbreitet? --Matthiasb(CallMyCenter)17:05, 6. Okt. 2011 (CEST)[Beantworten]
Zustimmung, größerer Einsatz erfordert eine Grundsatzdisk. Ich sehe das schon bei den (missbräuchlichen) Einsatz der Navis innerhalb der Artikeln so. --Atamari16:35, 11. Okt. 2011 (CEST)[Beantworten]
Das hat Bergi schon vor Ewigkeiten repariert. Es muss nur ein Admin von hier den Quelltext übernehmen und dabei die Zeile var Isrc = "/media/wikipedia/commons/"; durch var Isrc = "/media/wikipedia/commons/"; und die Zeile if (! $.inArray(i, rmEditButtons)) { durch if ($.inArray(i, rmEditButtons) != -1) { ersetzen. --Schnark09:32, 7. Okt. 2011 (CEST)[Beantworten]
jetzt nicht mehr, stolz quatdratisch und wohlgenährt, ein hoch unseren programmieren hinter den kulissen, den vielgeschmähten -- W!B:21:09, 7. Okt. 2011 (CEST)[Beantworten]
Zumindest in meiner - etwas antiquierten - Softwarekonfiguration (Opera 9.10.521 auf Linux i686 2.4.20-8 RedHat) fehlen hinter den extrenen Links die Dateisymbole. Die Lücke für die Symole ist vorhanden, und dieser erweiterte Zwischenraum gehört auch noch mit zum anklickbaren Link, aber das Symbol selbst fehlt. -- M.ottenbruch¿⇔!RM15:22, 6. Okt. 2011 (CEST)[Beantworten]
Gibt es zufällig irgendwo einen Screenshot von einer Weiterleitung von vor der Software-Umstellung? Bin mir jetzt auch nicht mehr sicher, ob sich da was geändert hat. SteMicha16:42, 11. Okt. 2011 (CEST)[Beantworten]
Ok, also fetter wie vorher ist es wohl nicht, aber die Buchstaben stehen auf jeden Fall enger beisammen. Skripte hab ich keine und softwaremäßig hat sich seit dem Update bei mir auch nichts geändert. SteMicha17:46, 11. Okt. 2011 (CEST)[Beantworten]
Sortierfunktion von Tabellen
Vorhin war das Symbol für das sortieren von Tabellen verändernt, jetzt ist es ganz weg. Dafür kann man die Spalten durch einen Klick in die Kopfzeile sortieren. Reichlich dämlich, denn a) sieht man nicht mehr welche Spalten sortierbar sind und welche nicht, b) muss man da erstmal drauf kommen (vor allem aus Sicht eines Users, der hier nur selten ist), und c) müssten so viele Tabellen-Beschreibungen bzw. Legenden angepasst werden, in denen das sortieren der Tabellen erklärt ist.--Nothere17:42, 6. Okt. 2011 (CEST)[Beantworten]
Dann gern noch einmal die Frage: Warum muss bei einem Update dermaßen viel verschlechtert werden? Kann mir das mal bitte dringend jemand erklären? So ein zeit- und nervenraubender Mist geht mir nicht in den Kopf. Wenn die Leute keine vermeintlichen Verbesserungen ("Die automatische Vergabe des Passiver-Sichter-Status wird jetzt im Rechtelogbuch vermerkt", toll...) vornehmen können, ohne was kaputtzumachen, dann sollen sie es doch bitteschön ganz lassen. Sauer, --ScooterBackstage09:44, 6. Okt. 2011 (CEST)[Beantworten]
Was ich nicht verstehe, warum man das ganze nicht erst einmal in einer Sprachversion vernünftig ausprobiert und erst dann auf alle anderen losläßt. Warum hat man das nicht erst einmal bspw. auf Commons applikiert und dann, wenn da alle Fehler beseitigt waren EN und danach uns. Dann sind die Sonderfälle wg. Sichten, Kätzchenbildverteil- und Artikelbewerungsfunktion weitgehend durch und der Rest vom Schützenfest hat wahrscheinlich keine Probleme mehr übrig, über die er sich beklagen kann. --Matthiasb(CallMyCenter)11:01, 6. Okt. 2011 (CEST)[Beantworten]
Logo. Translatewiki-Änderungen brauchen immer bis zum nächsten "Abzug", bis sie aktiv werden. Das kann "nächste Nacht" sein, oder auch einen Tag später. --Guandalug15:32, 7. Okt. 2011 (CEST)[Beantworten]
Diese Spezialseite hat sich verändert. Wenn man einen Artikelnamen eingibt und auf anwenden klickt, ist der Reiter links oben nicht mehr "Spezialseite", sondern "Artikel". Es ist also durch klicken darauf nicht mehr möglich, die Spezialseite zu aktualisieren. Stattdessen kommt man jetzt auf den Artikel. Ich halte das für eine Verschlechterung. SteMicha19:19, 6. Okt. 2011 (CEST)[Beantworten]
Das war von anderen Benutzern extra gewünscht, damit das Navigieren möglich bleibt. Spezial:Verschieben verhält sich genauso. Das Aktualisieren einer Seite kann man mit F5 oder einem Button des Browsers erreichen, was natürlich eine kleine Umstellung bedeutet. Der Umherirrende19:24, 6. Okt. 2011 (CEST)[Beantworten]
Ich finde es immer wieder beeindruckend: Irgendwer schlägt was vor, ein paar weitere nicken zustimmend und flugs wird's geändert, ohne daß nachgedacht wird, ob das überhaupt sinnvoll ist. Daß aber von der Änderung Millionen betroffen sind, denen das ganze nicht gefällt, scheint kein Schwein zu interessieren. Das war genau dasselbe mit der Sortierung in der AJAX-Suchanzeige, wo noch heute der betreffende Programmierer meint, er hätte was gutes getan. Einen Schmarren hat er, Scheiße fabriziert hat er. Nur ist diese Scheiße schon zwei Jahre alt und die meisten haben vergessen, dasses mal besser war. Kopf -> Tischplatte. --Matthiasb(CallMyCenter)20:21, 6. Okt. 2011 (CEST)[Beantworten]
Jep. Wenn man wenigstens die BKLs bevorzugt anzeigen würde, aber es gibt Fälle, da erscheint die BKL nicht im Suchfeld, weil sie ja in der Regel gar nicht verlinkt ist. --Matthiasb(CallMyCenter)08:53, 7. Okt. 2011 (CEST)[Beantworten]
Genauso wie der Browser einen Aktualisieren-Button hat. Das Wegnavigieren von der Seite ist mit der jetztigen Änderungen viel einfacher. Vielleicht werden es Neulinge besser finden. Keine Ahnung. Der Umherirrende20:53, 6. Okt. 2011 (CEST)[Beantworten]
Wir werden es vielleicht aufgrund der Hilfeanfragen auf dieser Seite merken. Vielleicht aber auch nicht, weil Neulinge oft nicht fragen, da sie nicht als blöd dastehen wollen. --Matthiasb(CallMyCenter)08:57, 7. Okt. 2011 (CEST)[Beantworten]
MW118: Table mw-collapsible mw-collapsed
dürfte auf der de-wp nicht funken. z.b. als {| class="wikitable sortable mw-collapsible mw-collapsed" ... wie hier. Das Ein/Ausklappen von Tabellen funkt aber ohne Problem am Test-Wiki. Das Einklappen von Abschnitten mit <div class="mw-collapsible mw-collapsed"> Bla Bla </div> in diversen Kombinationen funkt auf de-wp.--wdwd20:06, 6. Okt. 2011 (CEST)[Beantworten]
Etwas ausführlicher: Hänge ?debug=true (oder falls die URL ein index.php?... enthält &debug=true) an die URL an, oder nenne zumindest mal eine Seite, wo es ein Problem gibt. Falls du nur CSS-Warnungen der Art "'important' erwartet, aber 'ie' gefunden." meinst, die sind beabsichtigt, würden sie fehlen, gäbe es eine fehlerhafte Darstellung im Internet Explorer. --Schnark12:11, 7. Okt. 2011 (CEST)[Beantworten]
nein, es gibt eigentlich eh keine probleme, ich will hier keinen stress machen (ist genug ;), mw:Extension_talk:WikiHiero dürte eher passend sein, falls welche auftreten
Bisher war das Suchvorschlagsfeld sehr gut zu bedienen. Seit dem Update bekomme ich ein winziges Feld vorgesetzt, in dem eine völlig unnütze Scrolleiste einen Haufen Platz wegnimmt. Das stört schon mal, weil nun noch weniger Platz für lange Seitennamen ist (einfach mal „Wikipedia:WikiProjekt“ eingeben: ein Haufen Einträge, ein Scrollbalken, man sieht immer nur „Wikipedia:WikiProj...“) Das Beste kommt aber noch: Klickt man nun auf einen Eintrag, wird nicht wie üblich die Navigation zur Seite gestartet, sondern der Text erstmal ins Suchfeld übernommen. Man darf also noch mal auf „Artikel“ klicken. Hinter dieser völlig unnützen benutzerunfreundlichen Änderung sehe ich überhaupt keinen Sinn.
Weiter gehts mit dem Sperrdialog. Da steht im Feld „Sperrdauer“ erstmal schön breit „Andere Dauer (englisch)“. Die restlichen Einträge brauchen nur halb so viel Platz. Ändert man die Einstellung nun auf eine konkrete Dauer (z.B. 6 Stunden), verschwindet das Zusatzfeld für die manuelle Sperrdauer nicht wie es sich gehört sofort, sondern blendet sich eine halbe Sekunde später mit einem schicken Effekt aus. Auch hier sehe ich überhaupt keinen Sinn.
Danke für diesen Müll, man sieht in der neuen Version deutlich, dass es einigen mehr um Animations- und Grafikschnickschnack geht als um Fehler, die ausgebessert werden müssen. Mit MW 1.18 ist gleich noch eine ganze Schippe mit obendrauf gekommen. --Inkowik20:31, 6. Okt. 2011 (CEST)[Beantworten]
Das mit dem Suchfeld kann ich nicht bestätigen, ich sehe keinen Unterschied zu vorher, weder was den Scrollbalken angeht, noch, dass beim Klick auf einen Link dieser ins Suchfeld übernommen wird (tut er nicht), sondern es ruft wie bisher gleich die Seite auf. SteMicha21:30, 6. Okt. 2011 (CEST)[Beantworten]
Benutzt du Vector? Dort funktioniert es tatsächlich noch. --Inkowik21:33, 6. Okt. 2011 (CEST) PS: Wenn ich oben schon gemäkelt habe, dann nun auch noch was postivies: Monobook-Seiten laden nun merkbar schneller. Das wird mit der Umstellung auf den Resourceloader zu tun haben.[Beantworten]
Ich kann deine Such-Probleme auch mit Monobook nicht nachvollziehen, der Kasten wird bei mir bis zu "Wikipedia:WikiProjekt Denkmalpflege/Öster…" ausgedehnt, ein Klick darauf führt direkt zur Seite. Hast du vielleicht in deinen Einstellungen die AJAX-Suchvorschläge deaktiviert und die Vorschläge stammen von deinem Browser, der sich deine bisherigen Eingaben gemerkt hat? --Schnark11:58, 7. Okt. 2011 (CEST)[Beantworten]
Das Problem ist, das man einzelne Seiten nicht unterscheiden kann, weil man nur den Anfang sieht. Damit wird dieses Feature ad absurdum geführt. Siehe auch das Bild, was ich mal produziert habe. --StG1990Disk.12:10, 7. Okt. 2011 (CEST)[Beantworten]
Das Problem besteht auch in Monobook nicht, wie meine Gegendarstellung zeigt. Leert mal testweise eure monobook.js/.css, vielleicht sind eure Probleme selbst gemacht. --Schnark12:19, 7. Okt. 2011 (CEST)[Beantworten]
Den Cache habe ich natürlich geleert. Im IE9 funktioniert es, das habe ich gerade mal noch überprüft. Firofox 8 mag jedoch nicht, aber wie gesagt, bis vor dem Update hat das auch unter Firefox 8 funktioniert. --StG1990Disk.12:38, 7. Okt. 2011 (CEST)[Beantworten]
Fehler wird einer angezeigt, nachdem ich auf bearbeiten geklickt habe, die Fehlermeldung betrifft aber die Extra-Editbuttons. Sonst mindestens 30 Warnungen zu falsch deklariertem CSS oder so. --StG1990Disk.12:49, 7. Okt. 2011 (CEST)[Beantworten]
Nachdem der Bot letzte Nacht den ganzen Abschnitt auch das, was teilweise noch unerledigt war archiviert habe, krame ich das nochmal raus, weil das eindeutig noch nicht erledigt ist. --StG1990Disk.18:05, 10. Okt. 2011 (CEST)[Beantworten]
Da ist kein einziger Fehler in deiner Auflistung, nur ein paar CSS-Warnungen. Ein letzter Versuch wäre es, sämtliche Browser-Plugins etc. zu deaktivieren. --Schnark09:26, 11. Okt. 2011 (CEST)[Beantworten]
Solche CSS-Warnungen sind für mich auch Fehler, wäre das CSS korrekt würde das ja nicht auftreten. Aber egal. Ich habe nochmal monobook.css und monobook.js gelöscht und alle Browser-Plugins deaktiviert und sowohl mit Version 8, als auch Version 4 getestet. Das Problem tritt immer auf. Da es vor dem Update nicht aufgetreten ist kann der Fehler nicht auf meiner Seite liegen. --StG1990Disk.10:20, 11. Okt. 2011 (CEST)[Beantworten]
Ohne diese CSS-Warnungen gäbe es Fehldarstellungen in allen Versionen des Internet Explorers.
Mit dem Update gab es tatsächlich eine Änderung an den Suchvorschlägen: Wenn der Browser von sich behauptet, er könne eine solche Liste selbst darstellen, dann wird auf diese native Browserunterstützung zurückgegriffen. Letztendlich ist es damit ein Bug im Firefox, der auf jeden Fall auch dort gemeldet werden sollte. Ich habe aber soeben im MediaWiki-Bugzilla darum gebeten, dieses Feature für Firefox zu deaktivieren, in Opera, wo die Vorschlagslisten ebenfalls nativ durch den Browser unterstützt werden könnten, ist es bereits deaktiviert, da dort ebenfalls irgendwelche Bugs auftreten. Also: Abwarten, oder einen Browser verwenden, der nicht behauptet etwas zu können, was er nicht kann. --Schnark11:09, 11. Okt. 2011 (CEST)[Beantworten]
Sogar Fehldarstellungen im IE9? Der soll doch angeblich endlich standardkonform sein. Solange absehbar ist, dass das von MediaWiki oder Firefox-Seite behoben wird kann ich damit leben. --StG1990Disk.11:59, 11. Okt. 2011 (CEST)[Beantworten]
MW118: Problem bei Darstellung von Bildern mit Hochkant-Befehl
Wenn man bei einem Bild den Befehl hochkant=0.x setzt, gibt es mal wieder Probleme mit der Darstellung - das Bild wird nicht angezeigt, der Browser lädt sich tot, bis man irgendwann den Versuch abbricht. Hat das auch mit MW118 (für mich jetzt schon meine Lieblingsabkürzung des Jahres) zu tun oder ist das der ganz normale Mist, der alle paar Wochen auftritt, ohne dass jemand erklären kann, warum? --ScooterBackstage21:43, 6. Okt. 2011 (CEST)[Beantworten]
Es gibt/gab Probleme mit den Image scalern ("21:25 guillom: image scalers have been having issues for the last ~20 minutes " [2] - Zeit in UTC). Die sind gefordert, wenn eine bisher nicht verwendete Bildgröße erzeugt werden muss. Wieso es diese Probleme gibt, weiß ich nicht. Es kann durch MW118 direkt oder nur durch die zusätzliche Lat durch die Umstellung hervorgerufen sein. Viele Grüße --Saibo (Δ) 03:14, 7. Okt. 2011 (CEST)[Beantworten]
Ich hatte heute nach einem Edit vom 3. Oktober ein etwas anderes Problem. Das korrekt hochkant aufgenommene Bild (erstes Bild - im Diff etwas nach unten scrollen) wurde rechts gedreht und gestaucht. Daher habe ich als provisorische Maßnahme das upright/hochkant=x.x weggelassen. Keine Ahnung was das war oder ist. Gruß -- AstrobeamerAsk the CEO22:25, 6. Okt. 2011 (CEST)[Beantworten]
Das Bild hat fehlerhafte EXIF-Daten: "Kameraausrichtung: Um 90° entgegen dem Uhrzeigersinn gedreht". Das stimmt nicht, denn es ist nicht gedreht (siehst du, wenn du es in einem Browser ansiehst). Mit dem 118er-Update dreht MW Bilder automatisch basierend auf den EXIF-daten, sodass man sie theoretisch direkt aus dem Foto hochladen kann, ohne sie manuell (oder per Rotatebot) drehen zu müssen. Leider haben die Devs nicht bedacht, dass es eine ganze Masse Bilder gibt, die falsche EXIF-DAten haben - so wie "dein" Bild hier. Ich habe die falsche Information nun gelöscht. Jetzt klappt es. Dir fehl der Fehler nur bei dem Hinzufügen von Hochkant auf, weil es die Skalierung des Bildes auf eine Größe änderte, die die Server noch nicht vorbereitet gespeichert hatten und sie daher (nun inkl. automatischer Drehung) erzeugten. Die Version ohne hochkant war noch gespichert und war noch von der alten (um das Dreh-Feature "ärmere") MW-Version erzeugt. Nach einem Purge (oder nach unbestimmter Zeit) wären alle Miniturbilder fälschlich gedreht gewesen.
Vielen dank für die Reparatur, aber das war nicht "mein" Bild. Und leider bin ich (und andere sicher auch) in Englisch nicht so fit, dass ich an solchen Diskussionen sinnvoll teilnehmen kann. Gruß -- AstrobeamerAsk the CEO07:17, 7. Okt. 2011 (CEST)[Beantworten]
Danke Dir Schwäbin für den Tipp. Ich muss aber zu besagtem Bild noch etwas loswerden und das betrifft eher Saibo. Ich fotografiere nun nicht seit gestern und weiß, dass es sich in diesem Fall normalerweise um ein Hochkantfoto handeln muss. Wenn ich meine Kamera (EOS 1000D) für so ein Foto drehe und ich die automatische Drehung eingeschaltet habe oder hinterher manuell drehe, dann steht in den EXIF-Daten eben "Um 90° (ent)gegen dem Uhrzeigersinn gedreht". Bei dem besagten Foto kann der Fotograf nur waagerecht auf der Erde gelegen haben und hat die Kamera nicht gedreht. Allerdings muss er dann das Bild in der Kamera oder mit einer Software gedreht haben. Gruß -- AstrobeamerAsk the CEO17:36, 7. Okt. 2011 (CEST)[Beantworten]
Ich weiß, dass es nicht dein Foto ist, aber du hast es hier gemeldet. Wenn in den EXIF-daten eine Drehung vermerkt ist, dann heißt das eigentlich, dass die physikalisch gespeicherten JPEG-Daten zur Anzeige gedreht werden sollten (ansonsten liegt das Bild).
Bei dem hier gefixten Hochkant-Bild hat die Kamerasensorik korrekt das EXIF-Tag "ist gedreht" gesetzt, aber der Fotograf hat wahrscheinlich das Bild dann mit einer Software physikalisch gedreht, die kein EXIF beherrscht (wie z.B. verbreitete Microsoft-Tools). Daher stand dann immernoch das EXIF-Tag "gedreht" drin, aber das Bild war gar nicht mehr gedreht. Viele Grüße --Saibo (Δ) 19:06, 7. Okt. 2011 (CEST)[Beantworten]
Im Artikel Rundkirche Zum Friedefürsten (Klingenthal) wird mir die Kirche in der Infobox auf die rechte Seite gekippt und verzerrt dargestellt. Auf Commons besteht das gleiche Problem bei der Ansicht des Bildes in den Vorschaubildern der Versionsgeschichte werden die Bilder aber „richtig“ dargestellt. Woran liegt das? Kann das jemand beheben? --WikiAnika18:20, 7. Okt. 2011 (CEST)[Beantworten]
Ich habe das entsprechende Bild mal "richtig" gedreht. Bilder können im JPG Format das Attribut "gedreht" enthalten. Die Daten dazu aber nicht. Damit scheint es wohl Probleme zu geben. --Alchemist-hp19:12, 7. Okt. 2011 (CEST)[Beantworten]
Ich wollte ihn auch schon dazu befragen ;-) Ich weiß nicht mal, von welchem EXIF-Tag er spricht (habe versucht, eine Diffansicht zu finden, aber die kipps ja nich). --Schwäbin19:43, 7. Okt. 2011 (CEST)[Beantworten]
Also das EXIF-Tag heißt im Original (englisch) Orientation. Bei normaler Kamerahaltung steht dort im Allgemeinen "Top left". Auf deutsch wird das häufig mit "Horizontal (nicht gedreht)" übersetzt. Es gibt etliche Programme - z. B. das für Privatanwender kostenlose IrfanView, die so etwas verlustfrei (also ohne Änderung der Kompression bzw. Dateigröße) ändern können. Ich hoffe, dass Dir das schon mal etwas weiterhilft. Gruß -- AstrobeamerAsk the CEO21:00, 7. Okt. 2011 (CEST)[Beantworten]
Danke. In den EXIFs meiner Kamera steht sowas nicht drin. Hast Du ein Beispiel für ein Commonsbild, in dem diese Eigenschaft drinsteht? (Ich drehe die Bilder jetzt werd ich gleich gesteinigt immer schon im Windows-Explorer in der Thumbnail-Ansicht.) Und wie würde man es dann entfernen? --Schwäbin21:10, 7. Okt. 2011 (CEST)[Beantworten]
Dreh die Bilder lieber in der Kamera oder mit IrfanView - Windoof kann das nicht. Bei Wikipedia (Commons) steht das unter Metadaten. Dort musst Du auf "Erweiterte Details einblenden" klicken. Dort heißt das dann "Kameraausrichtung". Hier mal als Beispiel ein Bild A380 von mir. Gruß -- AstrobeamerAsk the CEO21:29, 7. Okt. 2011 (CEST) PS.: Wieso bin ich bei Commons nicht mehr automatisch eingeloggt?[Beantworten]
Danke fürs Beispiel. Bisher hat das mit dem Drehen meiner Bilder immer funktioniert. Login: Wahrscheinlich hängt das damit zusammen, dass jetzt alle, die programmieren können, hektisch Fehlerbehebung betreiben. Habe mich falsch ausgedrückt: Windows kann zwar drehen, allerdings nicht verlustfrei. AstrobeamerAsk the CEO22:02, 7. Okt. 2011 (CEST)[Beantworten]
Die Bilder drehen und gleichzeitig das entsprechende EXIF-Tag korrigieren kann auch das Komandozeilenprogramm jhead: der Aufruf jhead -autorot *.jpg müsste auch unter Windows funktionieren. Und falls nur das EXIF-Tag falsch ist (weil z.B. der Lagesensor in der Kamera die Kameradrehung niht richtig erkannt hat), kann man das auch mit jhead -norot Bilddatei.jpg korrigieren --Jumbo143522:03, 7. Okt. 2011 (CEST)[Beantworten]
Was passiert hier bei der Bilddarstellung? Dasselbe Bild, nur in verschiedenen Größen. Oder ist das auch ein neues Feature von MW 1.18? Versucht zu purgen habe ich schon, das hat nichts gebracht. --bjsMS10:06, 8. Okt. 2011 (CEST)[Beantworten]
Und was macht man, wenn man keine chirurgischen Eingriffe in Bilder vornehmen kann, um irgendwelche EXIF tags operativ zu entfernen? --bjsMS11:04, 8. Okt. 2011 (CEST)[Beantworten]
Auf Hilfe aus der Community hoffen. Oben oder auf Commons (link steht auch irgendwo) sind einige Hilfsmittel genannt, mit den es einfach gehen soll. Ich habe die selber aber noch nicht genutzt. Der Umherirrende13:23, 8. Okt. 2011 (CEST)[Beantworten]
Das ist eine nicht richtig umgesetzte neue Funktion von MW 1.18. Generell: abwarten - es wird daran gearbeitet.
Konkret zu dem Bild: "Kameraausrichtung Um 90° im Uhrzeigersinn gedreht" bzw. "Orientation: Rotate 270 CW" stand (falsch(!)) im EXIF-Tag des Bildes, weil das Bild von einem Programm gedreht wurde (z.B. MS Photo Gallery), was kein EXIF berücksichtigt. Habe es in neuer Dateiversion korrigiert. Bei wichtigen, aktuell in Artikeln verw. Bildern können wir das von Hand machen. Ansonsten auf eine Softwareverbesserung/Botlösung warten. Viele Grüße --Saibo (Δ) 17:01, 8. Okt. 2011 (CEST)[Beantworten]
An der MS PhotoGallery dürften die falschen Einträge aber nicht liegen, das kann zwar mit den EXIF-Daten nicht umgehen, aber wenn man damit ein Bild dreht wird der EXIF-Eintrag Ausrichtung automatisch auf "Standard" zurückgesetzt (zumindest bei Win7). --149.201.29.5912:10, 24. Okt. 2011 (CEST)[Beantworten]
Vielen Dank. Werde das Bild gleich wieder in die Tabelle einbinden, aus der es wegen dieses Darstellungsfehlers rausgeflogen ist. Grüße --bjsMS19:08, 8. Okt. 2011 (CEST)[Beantworten]
Ja, es gibt noch viel viel mehr fehlerhafte EXIF-Tags (ja, sie sind wirklich fehlerhaft - die Frage ist nur, ob man sie überhaupt beachten sollte ;-) ). Das Bild habe ich zum Drehen beauftragt. Luxo und ich sind mit der Anpassung des Rotatebots an das neue Software verhalten fast fertig. Vermutlich in ~ 24h wird das Bild gedreht sein. Ich werde die rotate-Vorlage hier dann auch sichtbarer ankündigen, wenn der Bot glattläuft. Viele Grüße --Saibo (Δ) 02:07, 10. Okt. 2011 (CEST)[Beantworten]
Vielen Dank daß das Problem bearbeitet wird. Als Rückmeldung: Nach meiner Erinnerung war Datei:Fredrik Reinfeldt 0c181 8620.jpg zuvor sowohl gedreht als auch gestaucht (Michelin-Männchen). Seit gestern hat sich das Bildformat anscheinend geändert und der Porträtierte sieht wieder schlanker aus, allerdings ist die Rotation geblieben, Gruß --Rosenkohl22:20, 10. Okt. 2011 (CEST)[Beantworten]
Automatische Drehhilfe (in maximal 6 Stunden durch user:Rotatebot (läuft alle 6 Stunden)) für Commonsbilder:
Um 90° im Uhrzeigersinn ↻ drehen: {{Rotate|90}}
Um 180° im Uhrzeigersinn ↻ drehen: {{Rotate|180}}
Um 270° im Uhrzeigersinn ↻ (= 90° gegen Uhrz.s.) drehen: {{Rotate|270}}
Einfach diese Bausteine auf die Dateiseite eines zu drehenden Bildes setzen. Die Angabe um wie viel gedreht werden soll, bezieht sich auf die von der Software neu generierten Miniaturbilder. In der Vorlage ist auch eines eingebaut (Vorschaufunktion nach dem Setzen benutzen!), welches höchstwahrscheinlich neu erzeugt wird, da es eine ungewöhnliche Größe hat. Also am besten nach jenem richten.
Vielleicht wird es in wenigen Tagen auch einen Knopf auf der Dateiseite zum Drehen geben. Damit ist es dann ganz einfach.
Von Seite der MediaWiki-Entwickler haben sich bisher nur Kleinigkeiten getan. Hier sieht man alle Bugs, die noch zu beheben sind (nicht durchgestrichen): bugzilla:31504 Viele Grüße --Saibo (Δ) 14:34, 13. Okt. 2011 (CEST)[Beantworten]
Gott sei dank habe ich seit einiger Zeit angefangen, alle EXIF-Daten aus den Bildern zu entfernen, bevor ich sie hochlade. Es geht niemanden etwas an, welche Kamer ich benutze und wann ich mich genau wo aufhalte. Dass Commons diese Daten überhaupt speichert und anzeigt, ist schon daneben, aber dass jetzt auch noch automatische Aktionen damit verknüpft werden, ist eine Unverschämtheit. Viele meiner alten Bilder werden falsch angezeigt, und dass, obwohl sie seit Jahren unbeanstandet richtig angezeigt wurden. Wer kommt nur immer auf so einen Bockmist? --AndreasPraefcke00:17, 24. Okt. 2011 (CEST)[Beantworten]
Die hier waren's: bugzilla:6672. Für neue Uploads ists ja gar nicht so verkehrt (wenn bald auch mal die 100%-Ansicht korrigiert wird). Man muss die Bilder nicht erst drehen, bevor man sie hochladen kann. Probleme gibts aber dann, wenn man Software benutzt, die EXIF nicht versteht und seine Bilder damit dreht. Dann erscheinen sie hier dann verdreht (kann man dann durch Rotatebot korrigieren lassen).
Gernerell ist die Anzeige der EXIF-Infos schon praktisch: zum URV-Fahnden. ;-) Wenn du nicht willst, dass diese Infos öffentlich sind, dann musst du sie vor dem Upload entfernen - wenn Commons sie nicht direkt anzeigen würde, brächte das dir nicht so wahnsinnig viel. Man kann sie sich ja dennoch z.B. auch direkt im Browser anzeigen lassen. Viele Grüße --Saibo (Δ) 21:55, 26. Okt. 2011 (CEST)[Beantworten]
MW118: Keine Anzeige der Bildverwendung auf commons
Auf der Beschreibungsseite in den Commons wird die Verwendung des Bildes in Wikipediaartikeln nicht angezeigt. Auf der deutschen Seite jedoch schon. ?action=purge scheint nicht zu helfen bzw steht nach der Ausführung nicht mehr in der Adressleiste des Browers (Opera) Bug?
Die globale Verwendungsanzeige (Verwendung von Commonsdateien in anderen Wikis außerhalb von Commons) funktioniert derzeit leider nicht. Viele Grüße --Saibo (Δ) 02:56, 7. Okt. 2011 (CEST)[Beantworten]
Bei der Bearbeitung eines ungesichteten Artikels erscheint seit der neuen Soft der Hinweis
Achtung: Du bearbeitest nicht die aktuelle, sondern eine ältere Version dieser Seite. Wenn du speicherst, wird diese als aktuelle Version neu gespeichert. Um die aktuelle Version dieser Seite bearbeiten zu können, brauchst du nur die Bearbeiten-Schaltfläche noch einmal anzuklicken.
Die vorherige Änderung ist in dem Artikel auch nicht zu sehen. Wahrscheinlich nur bei nicht angemeldeten Benutzern. Mehrmals aufgefallen, z. B. Nippon Kaiji Kyokai. Es läßt sich vermeiden wenn ich vorher auf Ungesichtete Änderungen klicke. Wo es mehr ungesichtetes gibt werdet ihr finden --217.246.206.20923:20, 6. Okt. 2011 (CEST)[Beantworten]
Oha, das ist natürlich unpraktisch (konnte es unangemeldet in Opera nachvollziehen) - da werden einige unangemeldete unabsichtlich die noch ausstehenden Änderungen revertieren... Danke für die Meldung. Ich meine nicht, dass das vor der SW-Umstellung schon so war, kann mich aber auch täuschen. Viele Grüße --Saibo (Δ) 02:59, 7. Okt. 2011 (CEST)[Beantworten]
Würde ich jetzt nicht unterschreiben, dass es die größte bisher dagewesene Katastrophe war/ist und dass alles berechtigt ist. Es sieht hier auch nur sehr viel aus, weil hier kreuz und quer geschreiben wird und Themen x-fach vorhanden sind... Richtige Diskussionsseitenbenutzung scheint eben schwierig zu sein.
Es sollte weniger Probleme geben, das ist klar. Und vor allem bei solch einschneidenden Änderungen wie der Beiträgenamensraumfilter oder die EXIFbasierte-Drehung einfach mal jemand vor dem Deplyoment die Communities um Feedback bitten (wobei das beim Beiträgenamensraumfilter ja sogar sozusagen ungefragt da war, aber ignoriert wurde). Fehler bei vielen unserer Scripte sind unvermeidlich: schlechte und veraltete Programmierung, aber auch Mangel an definierten Schnittstellen. Es wird sich aber hier in Zukunft vielleicht auch was tun (habe ich zumindest gehört, dass es (von freiwilligen Programmierern her) am Laufen ist): globale Gadgetsverwaltung. Heißt: es muss nicht mehr jedes einzelne Projekt hergehen und Zeug fixen. Viele Grüße --Saibo (Δ) 05:29, 7. Okt. 2011 (CEST)[Beantworten]
soviel fieses gejammere wie hier ist wirklich ein skandal: ich find das eine super sache, dass es mal ein paar tage nicht 100% funktionieren, damit unsere bornierte autorenschaft mal checkt, welche arbeit hinter den kulissen zu tun ist, um das werkl am laufen zu halten: und die wird auch nicht bezahlt .. wirklich eine peinliche vorstellung, die sich die communitity (bzw., ein teil davon) hier leistet, statt einfach mal danke zu sagen: danke an unsere programierer! -- W!B:21:15, 7. Okt. 2011 (CEST)[Beantworten]
Auch wenn man freiwillig arbeitet, so kann man sich doch auch etwas mehr Zeit nehmen und vorher, mal mit ein paar Freiwilligen, einige Tests durchführen. Ich nenne so etwas schlichweg: völlig unvorbereitet, chaotisch. Ich spreche aus Erfahrung weil ich im echten Leben ein Sysadmin bin. Bei solch einer Katastrophe wäre ich längst rausgeflogen. Trotzdem möchte ich den Programmierern danken, weil ich weiß was das für eine Scheiß Arbeit ist. -- Alchemist-hp21:33, 7. Okt. 2011 (CEST)[Beantworten]
@Astrobeamer: Ich weiß ja nicht, was mit deinem Gedächtnis los ist, aber ich kann mich noch sehr gut an ein Software-Update erinnern, bei dem es deutlichvielmehrBeschwerden (ich könnte auch noch ein paar mehr Links angeben, aber so viele Buchstaben haben die Wörter halt nicht) gab, auch die Umstellung auf die Version 1.17 führte zu mehr Problemen und mehr Protest.
Wer in einem Wiki mit ausschließlich stabiler Software arbeiten will, der ist hier falsch, die WMF betreibt eben nicht nur Wikipedia und ihre Schwesterprojekte, sondern entwickelt auch die zugrunde liegende Software Mediawiki und benutzt Wikipedia dazu als Beta-Test, und dabei kann und wird es eben auch zu zeitweiligen Problemen kommen. --Schnark09:45, 8. Okt. 2011 (CEST)[Beantworten]
I beg to differ ... Freiwilligkeit ist keine Entschuldigung für Arroganz und Rücksichtslosigkeit, weder aufseiten der Autoren noch aufseiten der Entwickler. Dass ich kein Geld für meine Arbeit bekomme, gibt mir noch lang nicht das Recht, anderen Leuten einfach mal schlechte Artikel, unnötig aggressive Diskussionsbeiträge oder dysfunktionale Software reinzuwürgen, und erst recht nicht das Recht auf die Begeisterung anderer Leute für das, was ich falsch mache. -- CarbidfischerKaffee?09:50, 8. Okt. 2011 (CEST)[Beantworten]
Das Problem ist nur, dass die bornierte Autorenschaft für 100% der Wikipedia-Inhalte verantwortlich zeichnet. Ohne Autoren kann man das ganze Projekt in die Tonne treten. Ein bornierter Autor10:59, 8. Okt. 2011 (CEST)[Beantworten]
Warum macht man in Zukunft nicht folgendes: Jeder Quark wird mittlerweile per Hinweisbalken an alle gemeldet. In Zukunft gibt es dann einen allgemeinen Hinweis, dass am Soundsovielten eine neue Version kommen soll und man bis dahin Zeit hat, auf dem Testwiki Sowieso seine Lieblingsfunktionen und das Aussehen seiner Lieblingsartikel zu testen. Spricht da irgendetwas dagegen? Viele von den jetzt gemeldeten Problemen wären IMHO bei einer etwas breiteren Testerbasis lange vorher bekannt geworden. Ich hätte zB sofort gesehen, dass ExtraEditButtons weg sind. Subtilere Probleme können natürlich trotzdem übersehen werden.
Warum sich die Programmierer angegriffen fühlen, verstehe ich nicht. Es wird ja im Wesentlichen nicht die Programmierung mies gemacht, sondern es geht darum, dass der Prozess, mit dem neue Versionen installiert werden, offensichtliche Schwächen hat. Das kann und soll man verbessern. Warum wird hier immer alles gleich polarisiert (die Autoren vs. die Programmierer)? --LeastCommonAncestor11:04, 8. Okt. 2011 (CEST)[Beantworten]
Die ExtraEditButtons sind ein lokales Helferlein (Wikipedia:Helferlein/Extra-Editbuttons), und gehört somit nicht zum Standard-Umfang einer MediaWiki-Installation. Man hätte es auf einem Testwiki ausprobieren können, aber das hätte von hier aus kommen müssen, nicht von einem MediaWiki-Programmier, der von dieser Funktionalität nichts weiß. Einige andere Fehler hier haben das ähnliches Problem. Sie sind Benutzer-Skripte die nicht vertestet wurden, oder Helferlein, die nicht vertestet wurden. Der Umherirrende11:11, 8. Okt. 2011 (CEST)[Beantworten]
@Umherirrender + LeastCommonAncestor: Dass die Extra-Editbuttons nicht mehr funktionieren werden, habe ich bereits im April bemerkt, woraufhin Bergi das Skript im Translatewiki getestet und korrigiert hat. Dass das einige Zeit dauerte, bis die Änderungen hier übernommen wurde, liegt eher daran, dass hier halt ein großes Chaos bei der Meldung von Fehlern stattfindet. --Schnark11:17, 8. Okt. 2011 (CEST)[Beantworten]
Für mich ist dieses Experiment, daß wir seit MW 1.14 erleben dürfen, zweimal im Jahr oder so einen Haufen Änderungen präsentiert zu bekommen, ein Schlag ins Wasser. Es hat sich gezeigt, daß das nix bringt, weil es den Entwicklern Stress verursacht und den Benutzern auch. Man sollte wie früher notwendige Änderungen dann einspielen wenn sie funktionieren und notwendig sind. Und alle Projekte auf einmal umzustellen ist halt nun mal Kokolores, weil dann alle Projekte gleichzeitig auch die selben Bugs melden. Die werden nämlich nicht ehere behoben, sondern die "deutschen" Bugmeldungen werden erstmal ignoriert, weil man sich erstmal um die "englischen" kümmert. Oder um die von Commons. Zumindest kommt es mir so vor. Im Falle der EXIF-basierten Drehung war übrigens das Feedback auf Commons schon vor dem Update da, wurde aber halt durchgezogen. Machen wir erst einmal und fixen dann das Problem. Ich frage mich, wieviele der mehr als zehn Millionen Dateien auf Commons solche falschen EXIFs haben. Warum das Feature offensichtlich künftig auf Dauer Probleme bringt, naja, wenn Bildbearbeitungssoftware wie die von Microsoft per se Blödsinn macht, werden wir künftig immer falsch gedrehte Bilder haben. Die dann wieder von genervten Commons-Nutzern per Bot gedreht werden muß, was wieder Wikistress verursacht. --Matthiasb(CallMyCenter)11:32, 8. Okt. 2011 (CEST)[Beantworten]
@Matthiasb: Ich hatte mich gestern kurz im Chat mit Brion unterhalten - ein sehr angenehmes Gespräch. Wir unterhielten uns auch über die EXIF-Sache (da ist Brion dran) und über die Kommunikation, die ich ihm auch als mangelhaft beschrieb. Ich denke einiges davon war ihm nicht so bewusst (seinen Kommentaren nach zu urteilen). Er sagte mir, dass er versuchen wird es deutlich zu verbessern. Eben gerade die Sache, dass etwa die bzgl. Fotos gravierende Änderung meines Wissens der Community einfach nicht bekannt war. Zu welchem Problem es kommen würde, war mir klar, als ich drei Tage vor dem Deployment über dieses Feature und seine Realisation las. Das war dann leider zu spät. Vielleicht hätten wir das Deployment von der Funktion noch verhindern können, aber dazu wäre ein Kontakt mit den Entwicklern nötig gewesen, den es meines Wissens nach nicht gab. Den Commons:Village Pump lesen sie halt nicht - und das ist teilweise auch gut so, das würde zu viel Zeit kosten. Es wird also hoffentlich zukünftig Änderungen an der Kommunikation geben. Die Entwickler machen uns ja keineswegs absichtlich unglücklich, sondern würden sich über Tests und Feedback freuen, aber wenn das nicht kommt, bleibt ihnen nur nach bestem Wissen zu handeln - und dem Wissen fehlt halt z.B. sehr viel über die Prozesse bei uns bzw. es ist ihnen nicht klar, dass solch unvorbereitete große Softwareänderungen uns und unsere Prozesse massiv stören. Ich denke es gäbe auch durchaus von unserer Seite aus Möglichkeiten die Kommunikation zu verbessern. Beispielsweise, wenn mehr erfahrene Leute testen würden und frühzeitig sich um Einsicht in die aktuellen Entwicklungen bemühen würden. Aber Testen und Kommentieren kostet eben auch einen Haufen Zeit - und die hat sozusagen keiner hier von uns. Viele Grüße --Saibo (Δ) 17:22, 8. Okt. 2011 (CEST)[Beantworten]
Solche Änderungen sollten "aggressiver" angekündigt werden. Wer nicht Kurier oder andere Benachrichtigungsseiten auf der BEO hat oder regelmäßig liest, hat von der Umstellung erst erfahren, als sie durchgeführt wurde. Dass dann kaum Feedback über geplante Änderungen kommt ist nicht verwunderlich. Zur Zeit wird mit regelmäßig wiederkehrenden Balken für eine Umfrage über die mobile WP geworben. Warum nicht das gleiche Mittel Nutzen um rechtzeitig alle User auf anstehende Änderungen hinzuweisen, damit diese Feedback geben können, bevor durch die Umstellung Fakten geschaffen werden? --Nothere17:41, 8. Okt. 2011 (CEST)[Beantworten]
+1. Ich persönlich würde sehr gerne Testen und Kommentieren (auch auf Englisch, wenn das dann direkter ankommt). Und ich bin überzeugt davon, dass ich da nicht der Einzige bin. Wie Nothere aber richtig erwähnt, beobachte auch ich nicht immer alles hier. Da wäre…
eine Mailingliste über die automatisch ein Mail bei mir landet
oder meinetwegen auch ein Bot der eine Info auf meine Disku. schreibt (Hey! Da fällt mir ein: Ich wollte eh schon immer mal nen Bot für WP schreiben. :-)
und eine zentrale Anlaufstelle à la mw:Quality Assurance (gibt's die nicht vielleicht anderswo ohnehin schon und ich kenn' sie nur nicht?)
@Saibo: Zwangsläufig wird die MediaWiki immer komplexer und somit auch schwerer zu überblicken, was irgendwelche Abhängigkeiten angeht. Und auch dadurch, weil Foundation, Nutzer und Entwickler nicht unbedingt übereinstimmende Meinungen darüber haben, wohin sich die Software entwickeln soll. Und die unterschiedlichen Projekte haben ganz unterschiedliche Bedürfnisse. Und weil nicht alle Bedürfnisse erfüllt werden können oder wollen, gibt es einen Haufen Kram, für den irgendwelche Skripte von nicht direkt in die MediaWiki-Programmierung eingebundenen Fachkundigen zur Verfügung gestellt werden und die teilweise auf dem Toolserver laufen. Daß es hier und da hakt, ist somit kaum zu verhindern, auch kann nicht das Verhalten der Vielzahl von Browsern und Betriebssystemen vorhergesehen werden. Als nicht besonders informatisch begabter Benutzer sehe ich den Flaschenhals vor allem in drei Punkten:
Die Dokumentierung, welche Tools und Skripte was machen und wo sie das in welcher Form abgreifen, ist lausig bis nicht existent – woher soll ein Entwickler wissen, wie sich die Änderungen auswirken, wenn er gar nicht weiß, wo es sich auswirken kann.
Es hakt am Testen. Wie erfahren Betatester, was wann neu ist? Die einschlägigen Stellen, Bugzilla und Revisionslisten sind da nur wenig hilfreich, denn die Betatester sind entweder keine Entwickler (dann verstehen sie nur Bahnhof) oder sie sind Entwickler (dann wissen sie gar nicht, was in welchem Projekte warum wie gemacht wird). Und oft genug machen das einzelne Projekte unterschiedlich, weil sie irgendwann eine Unzulänglichkeit der Vorvorvorvorversion durch einen individuellen Workaround gelöst haben. Ganz zu schweigen von tw. anders definierten CSS-Klassen. (Wieder das Beispiel der GV: erst deren Einführung machte bewußt, daß das Verwenden der Klasse für die Inhaltstafeln zur Infoboxenformatierung keine gute Idee war, zuvor spielte das keine große Rolle.) Ganz zu schweigen davon, daß ein Betrieb unter Volllast gar nicht simuliert werden kann.
Es werden willkürlich irgendwelche Lösungen implementiert, für die es eigentlich kein tatsächliches Problem gab. Ein Beispiel ist die Bilderdrehung, das wurde schon thematisiert. Ein anderes Beispiel war die vorübergehende Abschaltung der Filterung der Beitragslisten nach Namensraum, die verbreitet auf Unverständnis stieß. Wenn das ganze schon tatsächlich zu Problemen geführt hätte, dann wäre das wohl akzeptiert worden, aber hier stand eher das "hoppla, ist das nicht ein wenig riskant, wenn tausend Leute gleichzeitig Ramm-Bot abfragen"-Vorsichtsprinzip zugrund, also der Fall des wie ich es nenne "Hollywood-Syndrom" (die Handlung vieler Hollywood-Filme funktioniert nur, weil sich die Akteure maximal idiotisch verhalten). (Ich kann mich irren, aber mir ist, daß das schon mal abgeschaltet war und dann von Tim Starling re-aktiviert wurde, weil der meinte, man sei zu übervorsichtig, aber vielleicht was das eine andere Funktion.)
Ideal wäre wohl, wenn man sagt, okay, wir basteln immer bis zum 28. Februar und 31. August und schalten das am 1. März und 1. September live auf die Testwiki. Und dann verändern wir nur noch Bugs. Und gehen nach einem Monat live, wenn es keine Probleme gibt. Nur wenn die diversen Skripte und Tools auf dem Testwiki gar nicht ausprobiert werden können, bringt es das auch nicht. Und wenn nicht die Vielfalt der unterschiedlichen Lösungen im Artikelbstand nicht auf dem Testwiki liegt, sondern beispielsweise nur ein Teil des Artikelnamensraumes, kann man bspw. das Verhalten von HotCat nicht ausprobieren, selbst wenn es auf dem Testwiki verfügbar wäre. Und wenn ein Betatester, um das Revertieren von Vandalismus per Skript oder wie auch immer (oben wird das nicht klar) auszuprobieren, erst mal vandalieren muß, um den Vandalismus dann beseitigen zu können und dafür von einem Testwiki-Admin gesperrt wird, dann ist das auch suboptimal. ;-) --Matthiasb(CallMyCenter)12:51, 9. Okt. 2011 (CEST)[Beantworten]
Was bedeutet bzw. was bewirkt die Option "Zugeordneter Namensraum" auf der Spezial-Seite "Änderungen_an_verlinkten_Seiten". Auf der Schnelle habe ich dazu nicht gefunden. --Atamari10:03, 7. Okt. 2011 (CEST)[Beantworten]
Ausprobieren. ;-) Wenn du z.B. "Benutzer Diskussion" als Namensraum wählst, dann ist "Benutzer" der zugeordnete Namensraum. liesel Schreibsklave 10:11, 7. Okt. 2011 (CEST)[Beantworten]
Den Sinn des Ausrufezeichens habe ich bislang auch noch nicht so recht verstanden, steht doch auch immer ein (Sichten) deutlich dahinter ... --Trigonomie - ☎11:20, 6. Okt. 2011 (CEST)[Beantworten]
MW118: Probleme mit der WP-Site im Internet Explorer
Mein IE versucht seit kurzem die WP.Site zu schliessen und sagt an: es hat Probleme mit der Site gegeben. Nach der Aufforderung, dies doch Microsoft zu melden, stellt der Browser die Site dann aber wieder her.
Das betrifft nicht nur den IE, sondern auch Safari. Mir scheint, als ob Wikipedia nur noch den Firefox richtig unterstützt oder die Entwickler haben nur neuen Mist programmiert ohne es ausgetestet zu haben. --Alchemist-hp
Komischerweise wird in den Artikeln Ubuntu oder Steve Jobs das [Bearbeiten] ohne persönliche Veränderungen komplett nach rechts und bei Artikeln mit Makierung (wie bei Ubuntu für Lesenwert,...) davor geschoben. Und dann steht noch unter der Hauptüberschrift ein "line -->"... Komisch. Technisches: Windows XP, 1024×600 Pixel, Firefox 7.0.1, Vector-Skin. Hat einer einen guten Rat? --IWorld – @20:35, 7. Okt. 2011 (CEST)[Beantworten]
Unter Monobook sind beide direkt neben der Überschrift. Unter Vector allerdings ist der Bearbeitenlink gaanz rechts direkt links neben den Auszeichnungsbuttons (ubuntu) bzw. rechts am FEnsterrand (Steve Jobs). (openSUSE, 1280 px Fensterbreite, Firefox 3.6, Monobook-Skin). Ein "line -->" sehe ich nicht. Viele Grüße --Saibo (Δ) 03:21, 8. Okt. 2011 (CEST)[Beantworten]
Wie kann ich das Ding denn jetzt an die Überschrift holen? Zudem sehe ich, dass "Java Console" mit meinem Browser derzeit unkompatibel ist... --IWorld – @21:46, 28. Okt. 2011 (CEST)[Beantworten]
MW118: Probleme mit einzelnen Tabellenzeilen, die nicht sortiert werden sollen
MW118 (?): Abfrage beim Zurückgehen auf eine Seite
Ich weiß nicht, ob das am Firefox liegt, aber ich kann's mir irgendwie nicht vorstellen, denn bisher hatte ich das noch nie: Als ich gerade eine Seite bearbeitet, aber noch nicht gespeichert hatte, aus dieser Seite heraus ein anderes Lemma anklickte und dann mit dem Zurück-Pfeil wieder auf die ursprüngliche Seite wollte, erschien die Abfrage, ob ich die Informationen noch einmal neu senden wolle. Ich befürchtete erst einen Datenverlust, aber der war nicht eingetreten. Verwirrend ist diese Abfrage aber schon, denn bis vorgestern war es kein Problem, zwischen gerade in Bearbeitung befindlichen und anderen Seiten hin und her zu springen. --ScooterBackstage00:59, 8. Okt. 2011 (CEST)[Beantworten]
Die Abfrage kommt/kam schon immer dann, wenn du auf die Seite auf die zu zurück willst mittels Senden eines Formulars gekommen bist. Hier ist das üblicherweise z.B. die Änderungsanzeige (also was du gegenüber dem gespeicherten Artikeltext geändert hast) oder die Vorschau (falls du JavaScript aus hast und deswegen die ganze Seite neuladen muss). Hattest du eines von beidem vielleicht, bevor du aus der bearbeiteten Seite heraus (wohl aus der Vorschau) ein anderes Lemma anklicktest, benutzt? Viele Grüße --Saibo (Δ) 03:10, 8. Okt. 2011 (CEST)[Beantworten]
Ein (unnötiger) Klick mehr erforderlich
Wenn ich auf meiner Beobachtungsliste einen Artikel per Mauszeiger-über-Lemma-streichen im sich öffnenden Drop-down-Menü „entobachten“ will, muss ich dies neuerdings noch mal extra auf einer sich neu öffnenden Seite bestätigen. Bisher enthielt diese Neuseite den Hinweis „Bratwurst wurde von Deiner Beo entfernt“. Stattdessen ist jetzt jedesmal ein zusätzlicher Klick erforderlich, der die Idee dieser Pop-ups (schnelleres Arbeiten) konterkariert. Kann man diese Verschlechterung nicht rückgängig machen? Gruß von --WwwurmMien Klönschnack09:31, 8. Okt. 2011 (CEST)[Beantworten]
Seit dem Update ist ein Token zum ent-/beobachten notwendig. Dies dient ein bisschen der Sicherheit, denn bisher war es möglich, dass beim Besuch einer fremden (!) Internetseite diese Seiten aus deiner Beobachtungsliste entfernt bzw. hinzufügt. Daher kommt es jetzt zu einer Sicherheitsabfrage, falls das Token nicht mitgeliefert wurde. Drüben wird bereits darüber diskutiert. --Schnark09:51, 8. Okt. 2011 (CEST)[Beantworten]
(BK) Um einen Artikel auf die Beobachtungsliste zu setzen oder zu entfernen wird aus Sicherheitsgründen ein Token verlangt. Die eingebauten Funktionen reichen das Token automatisch weiter. Du verwendest hier sicherlich eine JavaScript-basierte Erweiterung. Diese muss um die Token-Funktion erweitert werden. Hier ist eine Anleitung: mw:ResourceLoader/Default modules#tokens. Was in Zukunft nicht mehr mit einem Klick funktioniert sind direkte Links aus dem Wikitext zum bearbeiten der Beobachtungsliste. Solche Links erfordern daher seit 1.18 eine Bestätigung. --Fomafix09:59, 8. Okt. 2011 (CEST)[Beantworten]
Die Links auch, aber vorallem der Unwatch-Link aus der E-Mail-Benachrichtung über Änderungen an beobachteten Seiten wäre sonst nicht möglich. Vorlage:Beobachten ist auch nicht mehr so schön, da könnte man aber mit JavaScript den Token dran basteln. Der Umherirrende10:09, 8. Okt. 2011 (CEST)[Beantworten]
Sicherheit bedeutet immer Arbeit. Es sieht so aus, das du bei dir nichts ändern brauchst, sondern du musst warten, bis aus der von Schnark verlinkten Diskussion eine Änderung erfolgt, da du das Skript direkt nutzt, und nicht eine Kopie davon. Der Umherirrende10:30, 8. Okt. 2011 (CEST)[Beantworten]
Bisher konnte man etwa eine Internetseite erstellen, die die Adresse ...title=Seite_die_ich_vandalieren_will&action=unwatch in einen unsichtbaren Frame lädt, und einen Link darauf großzügig auf ein paar gut besuchten Seiten verteilen, ein paar Tage abwarten und schon wäre die Seite deutlich vandalismusgefährdeter, zumindest in Projekten ohne Sichtung.
Oder man hätte in den unsichtbaren Frame die Adresse ...title=Irgendetwas_Interessantes&action=unwatch laden können und den Link darauf nur einem einzigen Benutzer auf die Diskussionsseite setzen und im Watcher-Tool nachschauen können, ob die Zahl der Beobachter um eins abnimmt oder nicht. Etwas mühsam, aber so hätte man herausfinden können, wer welche Seite beobachtet. --Schnark10:49, 8. Okt. 2011 (CEST)[Beantworten]
Leerzeilen am Bearbeitungsanfang
Weil Leerzeichen am Anfang des Editfensters nicht mehr softwareseitig entfernt werden, kommt es zu unschönen Leeräumen in der Ausgabe vor allem bei Bot-Edits, bei denen man dann hinterherräumen muss. [3]. SteMicha10:57, 8. Okt. 2011 (CEST)[Beantworten]
Da wäre früher aber immer noch ein Leerzeile stehen geblieben, daher muss der Botbetreiber da eh dran, würde ich sagen. Wer am Anfang einer Seite die Vorlage entfernt, sollte auch darauf achten, das die Leerzeilen entfernt werden. Der Umherirrende11:01, 8. Okt. 2011 (CEST)[Beantworten]
(BK) Und warum meldest du das hier und nicht auf der Diskussionsseite des Botbetreibers (der ohnehin noch einen anderen Bug beheben muss)? --Schnark11:03, 8. Okt. 2011 (CEST)[Beantworten]
Es ist sinnvoll, wenn man beispielsweise das Preload zu dieser Seite bearbetiet möchte, weil dann die Leerzeilen am Anfang stehen bleiben. Durch die Leerzeilen kann der Benutzer direkt oben Anfangen und schreibt nicht unter der Signatur, früher gingen die immer verloren, wenn man etwas geändert hat. Der Umherirrende12:10, 8. Okt. 2011 (CEST)[Beantworten]
;-) Wenn man oben auf "neuen Abschnitt anlegen" klickt, steht ja schon Text im Bearbeiten-Fenster. Damit der Fragende über den Kommentar anfängt zu schreiben, befinden sich vor dem Kommentar zwei Leerzeilen. Es war vor der Änderung schwierig, sie dort hinzubekommen. Der Umherirrende20:30, 10. Okt. 2011 (CEST)[Beantworten]
MW118: Neuanlage nicht mehr als "kleine Änderung"
Wieso kann ich eine Neuanlage nicht mehr als "kleine Änderung" kennzeichnen? Das mag jetzt nicht dramatisch sein, aber ich habe das beispielsweise immer beim Anlegen eines Redirects getan und verstehe den Sinn hinter dieser Modifikation nicht. --ScooterBackstage09:05, 9. Okt. 2011 (CEST)[Beantworten]
Die Leisten für Artikel und Diskusion unterscheiden sich seit dem Update nicht mehr.
Vorher waren die Leisten durchaus unterschiedlich, was auch sinnvoll war und unnötige Aufblähung vermied. Beim ersten Versuch war die Button-LEise von Artikel überall, dadurch konnte ich nicht mehr ohen Weiteres signieren. Das Problem besteht nicht mehr - jezt ist die Button-Leiste Wikipediaweit, überall absolut identisch - und das ist extrem nervig. Wenn ich mien monobook jezt wider einschalte, paßt die nämlich cnith mal mehr in eine Zeile. Aber auch ohne monobook verschwendet z.B. der Sig-Button bei Artikel für anderes benötigten Platz.
Außerdem sind die Helferlein auch nicht wirklich wieder normal da. Der Button für die Sig sieht ja an für sich anders aus, als Standard - ich habe aber nicht den Button der Helferlein, sondern den Standard-Button. --Sarkanafrag den ℑ Vampirbewerte mich16:28, 11. Okt. 2011 (CEST)[Beantworten]
Keine Nachfrage mehr bei ungespeicherten Änderungen
Wenn ich eine Bearbeitungsseite verlasse, ohne vorher die Änderungen gespeichert zu haben, kommt keine Nachfrage mehr. Zum Glück habe ich in letzter Zeit keine größeren Änderungen gemacht. Vielleicht sollen wir ja auch nach jedem Satz auf "Speichern" klicken. Ich benutze Firefox 3.6. --DanielHerzberg17:55, 16. Okt. 2011 (CEST)[Beantworten]
Es gibt einen Bug, dass die Nachfrage nicht erscheint, wenn man die Bearbeitenseite über die Suche verlässt (den gab es aber schon immer). Außerdem gibt es wohl irgendwelche Probleme im Internet Explorer, die auf ein nicht standardkonformes Verhalten dieses Browsers zurückzuführen sind. --Schnark09:44, 18. Okt. 2011 (CEST)[Beantworten]
Hallo liebe Leute, die Buchfunktion hat Probleme, die hier schon mal angemerkt wurden. Leider reagiert dort scheinbar niemand. Wo wäre die richtige Stelle? Gibt es schon eine Lösung und ich find sie vielleicht einfach nicht? --Nati aus SythenDiskussion12:59, 19. Okt. 2011 (CEST)[Beantworten]
Ja, die Seite ist richtig. Lange Reaktionszeiten (oft mehrere Wochen) sind da allerdings normal :-( Benutzer:Volker.haas (einer der Entwickler der Buchfunktion) ist sogar seit Juni nicht mehr aktiv gewesen ... Hmm, vielleicht mal per eMail nachhaken, ob er überhaupt noch aktiv ist? (Ich weiß nicht, wer da außerdem noch entwickelt.) Gruß --Schniggendiller Diskussion 18:54, 19. Okt. 2011 (CEST)[Beantworten]
Ich kopiere hier mal den Fehlercode für das Abspeichern im Wikipedia-Namensraum hin, das sieht mir schwer nach einem durch das Update auf 1.18 verursachten Fehler aus, von daher verschiede ich das dann auch unter den entsprechenden Menüpunkt. --Nati aus SythenDiskussion19:30, 19. Okt. 2011 (CEST)[Beantworten]
Unexpected non-MediaWiki exception encountered, of type "UsageException"
badtoken: Invalid token
Er bekam das Recht am 6. Oktober bevor er am 7. Oktober gesperrt wurde. Das Recht wird wohl nur bei leerem Sperrlogbuch erteilt, aber bei einer Sperre nicht wieder entzogen. Das heißt wohl, dass wir Sichterrechte nicht mehr entziehen können. Nicht wirklich sinnvoll... --Engie00:37, 17. Okt. 2011 (CEST)[Beantworten]
o-O. Klingt nicht gut. Hab grad schon bei dem mit den Hexerkräften angefragt; wenn der nicht kann, dann niemand hier. Ich schätze mal, der kann dann wahrscheinlich auch nicht. :-( --Geitost17:09, 17. Okt. 2011 (CEST)[Beantworten]
ÖEy, das wird allmählich kafkaesk (nicht die bibi, sondern die sichter-auseinanderklamüserei). was soll dann der ganz mist, wenn duffyduck passiver bleibt? ich denk, man sollte die automatisierte erteilung von sichterrechten entweder zeitlich/editmäßig nach hinten verlagern (und dann auf die erteilung passiver sichterrechte verzichten) oder man erteilt sichterrechte nur noch händisch. was hier aber gerade durchsickert, ist ein blick auf hanebüchene jetzt-machen-wir-einfach-mal-stümperei. ein mb ex ante dafür wurde nicht für nötig erachtet, ein mb ex post zu initiieren wird sich wohl kaum einer zumuten wohlen.
Eine sichter-gruppen-auseinanderklamüserei, die am ende aus jedweden gründen auch immer dann doch nicht durchgehalten werden kann (siehe duffy), macht nur wenig sinn und schafft nur verärgerung. nicht alles was dv-mäßig machbar ist und aus gewissem sichtwinkel auch sinn ergeben mag, ist deswegen gleich der weisheit letzter schluss und sollte eben nicht ohne vorhergehendes mb installiert werden. F.19:51, 17. Okt. 2011 (CEST) (pffffft - druckreduzierung erfolgt)[Beantworten]
Laut Dokumentation wird das Recht automatisch nicht wieder entzogen, wenn die Kritieren nicht mehr zustimmen. Es ist aber dafür gesorgt, dass einmal automatisch vergebende Rechte nicht wieder erteilt werden. Wir können nur auf die Konfigurationsänderung warten. Der Umherirrende19:56, 17. Okt. 2011 (CEST)[Beantworten]
Ein nichtbpassiver Sichter erzeugt also durch Editieren einer gesichteten Version eine ungesichtete? Und kann sie dann als aktiver Sichter wieder sichten? Sehr merkwürdig oder "großes Erstaunen" --Eingangskontrolle19:51, 19. Okt. 2011 (CEST)[Beantworten]
Das bedeutet ja, dass der Bug nicht als Bug weiterbehandelt und gefixt werden soll, sondern als so genanntes "neues Feature" in die nächste Version eingebaut werden soll.
Remember: Jemand schrieb, zwischen dieser und der letzten Version lagen ca. 8 Monate oder so. Also werden wir hier mit dem neuen Problem, das erst seit dem Update aufgetaucht ist, nun die nächsten ca. 8 Monate zu kämpfen haben. Ich bin dafür, dass so lange dann auch niemand mehr automatisch passiver Sichter wird, solange das Recht nun neuerdings nicht mehr entzogen werden kann durch Kurzsperre. Hier geht es um einen neuen Bug, egal wie das nun zustande gekommen ist. Es ist ein neuer Fehler, darauf muss zeitnah reagiert werden. Das sollte man nicht um 8 Monate verschieben. Also entweder keine passiven Sichterrechte mehr vergeben lassen oder diese zumindest erst dann, wenn auch der automatische aktive Sichterstatus erreicht wurde. Sonst ist das total bescheuert so. Bei normalen Softwareupdates werden solche Fehler kurzfristig gefixt und nicht erst auf irgendwas viele Monate später gewartet. Dann wäre es besser, man würde die Änderung ganz rückgängig machen bis zur nächsten Updateversion, dann wäre das Problem keins mehr. Man kann doch nicht was einführen, das dann dauerhaft Probleme bereitet, und diese Probleme nicht zeitnah fixen wollen. *kopfschüttel*
Könnte jemand mit Zugang bei Bugzilla mal deutlich machen, dass es dann besser wäre, wenn man keine passiven Sichterrechte mehr vergibt oder die Neuigkeit rückgängig macht, da wir es hier mit einem neuen Problem zu tun haben, das es erst seit dem Update gibt? Ich habe das Gefühl, das ist dort noch nicht angekommen. Bitte schreibe jemand dort in den Bug deutlich hinein, dass vor dem Update der passive Sichterstatus durch Kurzsperre entzogen werden konnte und den Status nun erst neuerdings niemand mehr entziehen kann. Dort wird davon ausgegangen, dass auch vorher niemand das konnte, das ist aber falsch. Und bitte schreibe jemand hinein, dass die Sichtungen mit diesem Fehler überflüssig werden und man sich das Sichtungssystem dann auch schenken kann, wenn irgendjemand mit gerade erst passiven Sichterrechten (die ja ziemlich schnell vergeben werden) Blödsinn damit baut und dieser jemand dann trotzdem seine Edits als gesichtet markiert bekommt. Dann hilft es nur noch, ihn endgültig zu sperren. Ist das wirklich so gewollt? --Geitost12:23, 22. Okt. 2011 (CEST)[Beantworten]
Nachtrag: Auch wenn diese Verschlechterung und ihre Folgen aus dem erwähnten Bug nicht deutlich hervorgehen und ebenso wenig, ob sich der Sache nun jemand Zuständiges annimmt, so sieht es nach dieser Verschiebung vom Umherirrenden so aus, dass die Anpassung der Software doch als Fehler bereits früher behoben werden soll. Kann man wohl nur hoffen, dass sie damit tatsächlich bald kommt. Keine Ahnung, ob das nun auch bei den zuständigen Hamstern so angekommen ist, im Bug liest es sich für mich jedenfalls anders. Wäre schön, wenn dort zuständige Personen auch mal bestätigen würden, dass daran gewerkelt wird. --Geitost13:18, 22. Okt. 2011 (CEST)[Beantworten]
Also, ich (Monobook, IE, Windows XP - muss man ja heutzutage dazuschreiben) kann unter Anzeigeoptionen (steht über den Änderungen) Markierte Änderungen ausblenden (auf "ausblenden" klicken). --MannMaus19:16, 8. Okt. 2011 (CEST)[Beantworten]
Benutzerseiten, und andere Dinge, die nicht gesichtet werden, werden auch gezeigt, aber die gesichteten Seiten werden (bei mir, ich bin vorsichtig, besonders nach dieser Softwareumstellung) ausgeblendet. Versuch doch mal, dir nur den Artikelnamensraum anzeigen zu lassen! --MannMaus19:22, 8. Okt. 2011 (CEST)[Beantworten]
23. Oktober 2011
Fehler: Bild ist ungültig oder nicht vorhanden
Bei dem Artikel Hluboké u Kunštátu wird unangemeldet statt dem roten Punkt der Fehler <imagemap>-Fehler: Bild ist ungültig oder nicht vorhanden angezeigt. Angemeldet wird es richtig angezeigt. Wo liegt der Fehler? --Fomafix11:05, 23. Okt. 2011 (CEST)[Beantworten]
Dieser Abschnitt kann archiviert werden. Der Umherirrende 12:11, 29. Okt. 2011 (CEST)
24. Oktober
Fotos in Baden-Württemberg
Ich hoffe ich bin hier richtig. Folgendes: heute habe ich im Internet die Webseite http://www.bw-jetzt.de/ gefunden, eine Marketingseite des Landes Baden-Württemberg. Im Suchfeld kann man eine beliebige Ortschaft eingeben und erhält dann Informationen. Bei der Stadt Schwetzingen dachte ich: "Das Foto kennste doch" und habe dann 20 weitere Ortschaften mit Wikipedia verglichen. Ausnahmslos jedes Foto kam aus der Wikipedia. Bei "Info" steht, dass alle Daten von Kooperationspartnern kommen. Im "Impressum" steht, dass alle Bilder urheberrechtlich geschützt sind und nur für den privaten Gebrauch vervielfältigt werden dürfen. Hat das alles so seine Richtigkeit und wenn ja, gibt es hier Informationen zu dieser Kooperation? Graf Foto --Graf Foto10:03, 24. Okt. 2011 (CEST)[Beantworten]
Es wäre möglich (ich halte es für wenig wahrscheinlich), dass der Anbieter mit den jeweiligen Rechteinhabern ein Sondernutzungsrecht vereinbart hat. Ich kann ja als Fotografin, die ihre Bilder bei Commons unter eine freie Lizenz stellt, dem Nutzer, der (beispielsweise in einem Buch) die verlangte Nennung von Namen und Lizenz nicht einhalten will, durchaus auch eine weitere Einzellizenz unter anderen Bedingungen gewähren. Das weiß dann allerdings der jeweilige Fotograf. Ich schlage daher vor, Du sprichst ihn/sie auf seiner Diskussionsseite darauf an. Sollte das Bild nicht lizenzgerecht genutzt worden sein, dann kann ohnehin nur er/sie als Rechteinhaber dagegen vorgehen. --Schwäbin11:04, 24. Okt. 2011 (CEST)[Beantworten]
<kwätsch>Es kann keine Kooperation geben, denn Wikimedia hat ja nicht die Rechte, um da was auszuhandeln. Diese haben nur die jeweiligen Fotografen. Was Du meinst, funktioniert in der Regel anders herum: Das Bundesarchiv stellt Wikimedia Commons Bilder im Rahmen einer Kooperation zur Verfügung oder ähnlich. --Schwäbin14:05, 24. Okt. 2011 (CEST)[Beantworten]
Da gibt es keine Kooperation, da bediente sich eine Werbeagentur lizenzwidrig an freien Inhalten. Einzige Möglichkeit ist, die Autoren/Urheber auf den Verstoß hinzuweisen, so dass sie entsprechende Schritte einleiten können. --92.196.44.15113:40, 24. Okt. 2011 (CEST)[Beantworten]
Das Staatsministerium BaWü hat nun Kenntnis von dem Problem und will sich mit der gebotenen Eile bemühen, für die nötige Lizenzkonformität bei der Nutzung der Bilder zu sorgen. Entweder direkt oder mit Hilfe der beauftragten Agentur. -- Mathias Schindler (WMDE)17:16, 24. Okt. 2011 (CEST)[Beantworten]
Danke Dir. Vielleicht könnte man ihnen noch sagen, dass die Seite nicht sehr professionell programmiert ist (ich konnte sie mit Firefox und NoScript gar nicht bedienen, nur mit einem völlig ungesicherten MSIE, und dann auch nur sehr mühsam. Zudem schreiben sie sogar die Ortsnamen falsch (Grossbettlingen heißt halt vor und nach der Rechtschreibreform in Wirklichkeit Großbettlingen). --Schwäbin17:19, 24. Okt. 2011 (CEST)[Beantworten]
Noscript bockiert nunmal alles was nach Flash riecht, ich nutze ebenfalls den FireFox + NoScript und konnte die Seite nutzen, nachdem ich temporär die Scripte zugelassen habe. Und man hat sich hier halt für KLickibunti entschieden. --Schraubenbürschchen20:36, 24. Okt. 2011 (CEST)[Beantworten]
Das ist mir schon klar, dass ich einzelne Skripte zulassen muss, wenn ich was sehen will. Gab dennoch Probleme. Nun ja, Esslingen Am Neckar – ich frage mich echt, woher die die Fehler beziehen, wenn sie doch bei Wikipedia abschreiben... --Schwäbin20:54, 24. Okt. 2011 (CEST)[Beantworten]
Vielleicht könnte die Agentur ja zumindest symbolisch ja einen Zehner pro genutzem Bild rausspringen lassen. einzuzahlen auf das Vereinskonto und die Benutzer bestimmen dann was mit ihrem ANteil geschieht. --Eingangskontrolle18:36, 24. Okt. 2011 (CEST)[Beantworten]
Auf der Seite liegt noch viel mehr im argen, da ist die staatliche Urheberrechtspiraterie geradezu ein Klacks dagegen... Was für eine unfassbare Stümperei. Meine Bilder sind auch verwurstet (ich weiß nicht, wie viele, da sowieso bei jeder zweiten Suche, egal welche Gemeinde man sucht, als Ergebnis Holzgerlingen kommt). Frecherweise nicht nur ohne Autorenangabe, das wäre mir persönlich egal, sondern in das feste Bildformat gepresst oder darauf gestreckt. Wir können alles außer Websites, mal wieder, wie so oft. --AndreasPraefcke12:19, 26. Okt. 2011 (CEST)[Beantworten]
Nur Pro Forma und auch noch falsch. Einige der Bilder verlangen eine bestimmte Art der Kennzeichnung, nämlich (c) Nutzername/Bilderhsoter (mit Link zu eben jenem) und nicht Benutzer Nutzername auf Bilderhoster (als Reintext). Zeugt davon, daß man gar nicht im Traum daran denkt, Lizenzen einzuhalten.--Sarkanafrag den ℑ Vampirbewerte mich18:52, 30. Okt. 2011 (CET)[Beantworten]
25. Oktober
Beobachtungsliste normal bearbeiten
Beim Versuch, unter Monobook meine Beobachtungsliste zu bearbeiten (über den Link Spezial:Beobachtungsliste_bearbeiten) habe ich grad nur folgende php-Fehlermeldung bekommen:
aus Wikipedia, der freien Enzyklopädie
Von Jumbo1435 (Beobachtungsliste: Änderungen | normal bearbeiten | Listenformat bearbeiten (Import/Export))
Wechseln zu: Navigation, Suche
MWNamespace::getTalk does not make any sense for given namespace -2
Media: nicht, nur Medium: - und zwar die Beobachtungsliste selbst. Wenn ich diese Zeile entferne und auf Beobachtungsliste aktualisieren klicke, kommt wieder diese Fehlermeldung (wobei ich den Backtrace jetzt nicht verglichen habe). Ebenso, wenn ich die Zeile Spezial:Beobachtungsliste mit entferne (schließlich will ich die Beobachtungsliste selbst ja nicht beobachten ;-)) --Jumbo143500:02, 25. Okt. 2011 (CEST)[Beantworten]
Nachtrag: Ich habe jetzt auch versucht, andere Namensräume aus der Beobachtungsliste zu entfernen (Datei:, MediaWiki:) - mit demselben Ergebnis. Und die Änderung scheint auch nicht gespeichert zu werden, denn wenn ich auf der Seite mit der Fehlermeldung wieder auf den Bearbeiten-Link klicke, ist die Liste wieder vollständig, also mit den Einträgen, die ich grad gelöscht hatte. --Jumbo143500:08, 25. Okt. 2011 (CEST)[Beantworten]
D.h. der Eintrag Spezial:Beobachtungsliste ist schuld?? Den hat die Software irgendwann selbst in die Liste eingefügt und ich hatte schon früher (also vor der Umstellung auf MW118) mal versucht, diesen zu entfernen. Naja, ich mach mir dann erstmal 'nen Tee --Jumbo143514:17, 25. Okt. 2011 (CEST)[Beantworten]
Du könntest das Beispiel aus dem Bug auch nutzen, um das wieder zu bereinigen. Musst aber dann genau wissen, was du für einen störenden Titel dort hast (Mit Medium oder Spezial als Namensraum) und das nachfolgende dann in der Adresszeile deines Browsers ausführen:
Dieser Abschnitt kann archiviert werden. Der Umherirrende 12:15, 29. Okt. 2011 (CEST)
MW118: Meldung: Bild ist ungültig oder nicht vorhanden
Bei sämtlichen Inseln von Bermuda (wahllos, z.B. Boaz Island) wird auf der Positionskarte der Fehler <imagemap>-Fehler: Bild ist ungültig oder nicht vorhanden angezeigt. Im Bearbeitungsmodus hingegen, ist alles in Ordnung, folglich stimmt der Satz "Bild ist ungültig oder nicht vorhanden" zweifellos nicht. Kann man den Fehler bitte wieder beheben? Danke. --Zollwurf11:58, 25. Okt. 2011 (CEST)[Beantworten]
Wir brauchen mehr Scripte und Tools die die Artikel und Bilder für die unterschiedlichen Benutzergruppen unterschiedlich ausgeben.
Bilder werden ja schon seit ca. 5 Jahren je nach Benutzergruppe unterschiedlich ausgegeben. Die gemeine IP bekommt seit es die Sichterei gibt nicht mehr unbedingt das aktuelle Bild. Da hilft nur purgen, entsichten/neu sichten (kann ich nicht) oder ein Nulledit um ein aktuelles Bild zu bekommen. Jetzt sind die angemeldeten auch mal dran - freut mich! Schade ist nur, dass ihr es für Euch (angemeldete User) richten werdet. Hoffentlich dürft ihr Euch bis dahin noch ordentlich damit herumärgern. --217.246.199.20113:46, 25. Okt. 2011 (CEST)[Beantworten]
In dem einen Beispiel (Boaz Island) ist der Fehler jetzt zwar verschwunden, bei allen anderen Inseln von Bermuda hat sich aber nix verändert. Es macht doch keinen Sinn, jedes Lemma noch mal manuell zu sichten - eventuell kann diese stupide Arbeit ja ein Bot übernehmen. --Zollwurf14:41, 25. Okt. 2011 (CEST)[Beantworten]
Das Problem ist schon länger alt. Es wird erst eine Lösung (hoffentlich) geben wen jemand einen Bugreport schreibt. Vor etwa einem Jahr waren es Sicons aus der Wikipedia:Formatvorlage Bahnstrecke die nicht angezeigt wurden. Die einzige Lösung die allen einfiel war: Entsichten/neu Sichten. Jetzt sind es die Icons der Georeferenzen. Wieder fällt niemandem etwas besseres ein. Es muss einfach mal jemand das Problem anfassen. In der zweit größten Wikipedia werden wir nicht mit aktuellen Dateien oder Texten (#Unangemeldet sehe ich eine alte Version des Artikels) bedient. --217.246.211.4020:05, 25. Okt. 2011 (CEST)[Beantworten]
Zuallerst: Der Cache hat mit dem Problem hier nur bedingt was zu tun, und das was du dort verlinkst, ist nicht spezifisch für dewiki, sondern gilt für alle Wikimedia-Wikis.
Außerdem ist es ja nicht so, dass sich keiner darum kümmert (siehe dort). Wir werden ja auch nicht dafür bezahlt, gefundene Bugs soweit zu verfolgen, dass man einen vernünftigen Bugreport verfassen kann, so dass die Entwickler den Bug soweit durchschauen um das Problem zu erkennen und zu lösen. Und mir persönlich fehlt die Kenntnis des Codes, um die Ursache des Bugs zu suchen. --Steef38920:38, 25. Okt. 2011 (CEST)[Beantworten]
OK, es kümmert sich jemand. Danke soweit! Es ist aber so wie ich bereits erwähnte, Entsichten/neu sichten ist das Mittel um die Bilder anzuzeigen. Eine nachhaltige Lösung ist es nicht. --217.246.211.17920:53, 25. Okt. 2011 (CEST)[Beantworten]
Immer dann, wenn der Name einigermaßen verbreitet auch ohne den ersten Vornamen auftritt, was man bei Händel und Eisenberg sicher bejahen kann, bei MLK jedoch sicher ausschließen. --Matthiasb(CallMyCenter)16:03, 25. Okt. 2011 (CEST)[Beantworten]
Also beim Gellert müsste ich schon nachdenken, wie den der zweite Vorname lautet. Wenn ihn jemand nennt, fallen mir bestimmt Häuser aus den Augen. Aber neben dem Gefühl gibt es auch den Häufigkeitsvergleich. --Eingangskontrolle23:36, 25. Okt. 2011 (CEST)[Beantworten]
Wenn ich den Fallback-Font richtig entziffere, müsste da Zeichen U+2028 gelöscht worden sein. Was das darstellt, weiß ich auch nicht, da mein Font den entsprechenden Glyph nicht dabei hat (sonst könnte ich das Fallback ja nicht sehen). --Jumbo143517:34, 25. Okt. 2011 (CEST)[Beantworten]
@Ianusius: Und warum hast du nur dieses eine Zeichen entfernt, nicht aber die beiden anderen in diesem und das letzte verbleibende im darauffolgenden Abschnitt? --Schnark09:44, 26. Okt. 2011 (CEST)[Beantworten]
Hab ich nicht gesehen – sie sahen ja so aus wie Leerzeichen. Das eine Zeichen hatte ich nur bemerkt, weil es den eingerückten Satz verschoben hat. -- ianusius: (↔Diskussion) 12:10, 26. Okt. 2011 (CEST)[Beantworten]
Ich habe nirgens eine Richtlinie gefunden wie dieses gehandhabt wird. Ich würde selbst sagen im Fleißtext lieber Millionen, in Tabellen uns Boxen Mio. --Dirkb21:07, 25. Okt. 2011 (CEST)[Beantworten]
Aber eine manchmal ziemlich dumme Dudenregel. Wichtiger als das sklavische Befolgen der "Bis-zwölf-Ausschreiben-Regel" ist es oft, dass vergleichbares gleich geschrieben wird. Gegenbeispiel: "Zehn Briefmarken zu 50 und 20 zu zehn Pfennig" ist doof, "Zehn Briefmarken zu 50 und zwanzig zu 10 Pfennig" richtig. --89.247.160.11313:12, 26. Okt. 2011 (CEST)[Beantworten]
Bitte nicht überflüßigerweise auf den Duden schimpfen, sondern in denselben reinschauen. Die Duden-Redaktion sieht das Thema nämlich durchaus differenziert. --84.172.19.4319:43, 26. Okt. 2011 (CEST)[Beantworten]
Seit dem Update funktioniert das Helferlein bei mir immer noch nicht wieder. Das merkwürdige ist, dass es nur im FF nicht funktioniert. In allen anderen mir vorliegenden Browsern kann ich mit dem Klick aufs Delta den Diff aufrufen. Beim FF ist der Diff schon da liesel Schreibsklave®22:22, 26. Okt. 2011 (CEST)[Beantworten]
Muss am Monobook und/oder einer Ergänzung (.js/.css) liegen, ich kann im FF das WikEdDiff unter Vector normal nutzen (es war nach dem Update nur kurze Zeit weg). --Schwäbin22:25, 26. Okt. 2011 (CEST)[Beantworten]
Sowas vermute ich auch und hoffe auf die Wikipedianer-Power um das Problem zu lösen, ohne dass ich mich selber drum kümmern muss. liesel Schreibsklave®17:05, 27. Okt. 2011 (CEST)[Beantworten]
Den Cache hast du geleert? Hast du WikiEd über Einstellungen – Helferlein oder individuell über .js eingebunden? Vielleicht beides und da beißt sich was? Vielleich mal komplett entfernen, Cache leeren, neu einfügen, Cache leeren. --Matthiasb(CallMyCenter)18:48, 27. Okt. 2011 (CEST)[Beantworten]
Wenn er von Spalte spricht, ist wohl eine Tabelle gemeint, denn im Fließtext gibt es keine Spalten ;-)
Ich habe aber die Frage so verstanden, daß er nur eine Spalte zentrieren oder rechtsbündig setzen) will. Deine Antwort hilft also nicht weiter, sondern das da. Er muß also in jeder gewünschten Zelle der Spalte style="text-align:right"| setzen, gefolgt vom Zelleninhalt. --Matthiasb(CallMyCenter)08:49, 27. Okt. 2011 (CEST)[Beantworten]
Die aktive Nutzung von WebCite in D (vermutlich ganz DACH) ist umstritten; manche meinen allerdings, es handle sich um das Begehen einer URV, wenn man diese Service aktiv nutzt (mit aktiv meine ich: du gehst hin und meldest eine URL zum Cachen). Manche argumentieren mit dem fehlenden Fair use im DACH-Recht. Der Dienst selbst sitzt in den USA und beruft sich auf eben dieses Fair Use einerseits und das Urteil im Verfahren gegen Google andererseits, mit dem Caching erlaubt ist. (Google behauptet ja, es cache, allerdings mit einer unendlichen Zeitdauer)
Es gibt in DE keinen Bot (und ich glaube nicht, daß wg. 2. einer unserer Botbetreiber aktiv werden würde). Es gibt/gab in EN einen solchen Bot, aber der Benutzer hat wg. anderer Streitigkeiten hingeworfen.
Kann man Timeline-Grafiken purgen? Im Artikel Essau ist die Grafik aus dem Ruder gelaufen, bildlich gesprochen ist dort ein Glas Wasser darüber gelaufen. Wenn man kein Purge ausführen kann, ist auch nicht schlimm - die Daten werden nächstes Jahr aktualisiert. --Atamari09:45, 27. Okt. 2011 (CEST)[Beantworten]
Was man natürlich machen kann, wenn man nicht ein Jahr warten will, ist es, den Parameter Max leicht zu verändern. Das hat keine sichtbare Änderung, außer dass der Server gezwungen wird, die Zeitleiste neu zu erstellen und damit korrekt darzustellen. --Schnark11:08, 27. Okt. 2011 (CEST)[Beantworten]
Änderung der einen Achse (s. Vorschlag) ist möglich, aber muss nicht (spätestens im nächsten Jahr sollte der Artikel erweitert bzw. überarbeitet werden). Die Infobox wurde (leicht) geändert, das hat aber keinerlei Auswirkung - wie die Daten (via {{Jahresdiagramm}}) - an die Timeline-Funktionalität übergeben wird. Ob noch mehr Grafiken davon betroffen sind (ist mir nicht bekannt)? Wird eigentlich Timeline irgendwie weiterentwickelt, ich habe den Eindruck, dass es nicht mehr verfolgt wird. --Atamari11:48, 27. Okt. 2011 (CEST)[Beantworten]
Was tun bei Falschaussage in Quelle?
Folgende Situation: Ein Artikel beruht zu nicht unwesentlichen Teilen (aber nicht nur) auf dem Buch eines Historikers. Nun gibt es eine Zeitungs-Rezension dieses Buchs von einem anderen, hochrenommiertem Wissenschaftler. Diese Kritik ist weitgehend substanzlos, weil der Rezensent das Buch offensichtlich nur kursorisch gelesen hat, aber das nur am Rande. Er wollte jedoch offensichtlich (dafür gibt es diverse Anhaltspunkte, ist aber hier nebensächlich) den Autor/das Buch niedermachen und bringt genau und nur einen echten Kritikpunkt, der den Autor allerdings als wissenschaftlichen Vollpfosten darstellt und in der Rezension auch entsprechend süffisant augebreitet wird. Der Vorwurf ist, der Autor habe eine Zahlenangabe über eine historische Personengruppe frei aus der Luft um das Mehrfache aufgeblasen. Der Rezensent sagt nun, es waren aber tatsächlich bekanntermaßen nur x Personen. Liest man nun beim Autor des Buchs nach, hat der aber tatsächlich auch nur von der Zahl x an Personen geschrieben (genau die, die der Rezensent als die korrekte nennt). Anders ausgedrückt: Der Vorwurf des Rezensenten ist falsch, und zwar nachprüfbar. Nun hat aber ein WP-Autor die entsprechende Kritikpassage breit und wörtlich zitiert in den Artikel geschrieben, mit der (offen erklärten) Absicht, das Buch als Quelle für den Artikel zu diskreditieren. Bitte nehmt mal an, dass das obige genau so stimmt - was ist hier die richtige Vorgehensweise? Ich kann ja schlecht hinter die Kritik schreiben: "Das stimmt übrigens gar nicht, prüft mal selbst auf Seite 324 nach." Nebenbedingung: Es ist nicht davon auszugehen, dass der andere WP-Autor auf die Einfügung der Quelle verzichtet. Danke für eure Einschätzungen. 217.7.150.12212:19, 27. Okt. 2011 (CEST)[Beantworten]
Versuch doch einmal folgende Ergänzung: Nach Name des Autors waren es aber tatsächlich nur X Personen(Einzelnachweis Buch Seite 324 wie üblich). --MannMaus12:28, 27. Okt. 2011 (CEST)[Beantworten]
Wenn man bei Falschaussagen den richtigen Fakt kennt, solle man nur diesen erwähnen. Entscheiden, ob eine Quelle richtig oder falsch liegt, dürfte noch im Rahmen dessen sein, was keine Theoriefindung ist. Alternativ kann man Widersprüche im Artikel auch darstellen; so, wie MannMaus es vorgeschlagen hat. Umweltschutz12:33, 27. Okt. 2011 (CEST)[Beantworten]
BK
Seltsame Frage - an sich ist doch jede Aussage in einer Quelle falsch, bis sie falsifiziert ist - dann verschwindet sie. Die zahlreichen Ausnahmen kommen durch Definitionen zusammen - dass München die Hauptstadt Bayerns ist oder dort ein Tempolimit von 50 km/h gilt, sind ja keine Tatsachen, sondern von Menschen definierte Aussagen, die insofern an sich stimmen. In wissenschaftlichen Arbeiten (zumal in der Geschichtsschreibung...) Wahrheit zu erwarten, ist schon seltsam... BerlinerSchule12:35, 27. Okt. 2011 (CEST)[Beantworten]
Danke für Eure Vorschläge. Der Vorschlag von MannMaus klingt gut. @BerlinerSchule: Wieso seltsam? Es ist nicht zu erwarten, dass die in der Zeitungsrezension verbreitete Falschaussage noch jemals falsifiziert wird, zumal das Thema ziemlich exotisch ist. 217.7.150.12212:38, 27. Okt. 2011 (CEST)[Beantworten]
Vor unserer Zeitrechnung
Heute ist mir auf meiner Beobachtungsliste eine Änderung der Zeitangabe 2000 v. u. Z. in 2000 v. Chr. aufgefallen. An sich nicht wirklich schlimm, nur glaube ich wirklich nicht an Chr., so dass mir die Angabe v. u. Z. doch eigentlich lieber und wertfreier wäre. Gibt es hier schon eine Diskussion dazu --Anna656612:44, 27. Okt. 2011 (CEST)[Beantworten]
Über die Einführung der Wikipedia-Zeitrechnung wurde noch nicht entschieden. Es kann ja nicht angehen, das wir hier ein durch einen christlichen Mönch willkürlich angesetzte Datum für die Geburt von Jesus Christus als Basis unserer Zeitrechnung nehmen. Daran ändert auch ein "v. u. Z." nichts. Ein Verschweigen der Ursprünge ist nur verlogen. liesel Schreibsklave®13:00, 27. Okt. 2011 (CEST)[Beantworten]
MultiBK:
Problem: Eine wertfreie gibt es zur Zeit nicht. Die abendländische ist letztlich christlich, die islamische ist eher islamisch, die buddhistische ist eher buddhistisch und so weiter. Die von Dir vorgeschlagene ist einerseits auch nur am (vermeintlichen) Geburtsjahr des Jesus von Nazareth orientiert, andererseits aber eindeutig nicht nur mit der kommunistischen Ideologie verbunden, sondern auch mit der Tatsache, dass diese Ideologie sie, wo und als sie Deutungshoheit beanspruchte und durchsetzen konnte, zumindest zum Teil durchgesetzt hat - also auch überhaupt nicht wertfrei. Eine neue wertfreie müsste her - aber woran wollen wir die festmachen? Und dann dauerte es auch noch, bis sie so etabliert wäre, dass sie zur Wikistandardkalenderrechnung befördert werden könnte... Und lies mal die seitenlangen Diskussionen zum Kreuz als Todeszeitpunktsymbol - das bleibt, auch für Nichtchristen (die als Gegenstände einer Enzyklopädie langfristig die Mehrheit unter den Personen sind), auch für Zoo-Eisbären, gelegentlich auch für Institutionen...
Das mit dem "Glauben" sollte kein Problem sein - wenn wir lesen, dass Caesar in seinem ersten Konsulatsjahr oder Stalin in seinem dritten Jahr als Generalsekretär dies oder jenes getan hat, dann müssen wir die genannte Person auch nicht verehren... BerlinerSchule13:04, 27. Okt. 2011 (CEST)[Beantworten]
Aber wir können ja mal (probehalber) ausrechnen, welcher Tag heute wäre, hätten wir den 7. August 1966 zum 1. Januar 0001 erklärt ("Januar" nur provisorisch, die Monate würden nach verdienten Admins benannt, klar). BerlinerSchule13:10, 27. Okt. 2011 (CEST)[Beantworten]
Quetsch: Au ja, --MannMaus 15:08, 23. März oder wie auch immer 0046 (CEST) (Ja, ich weiß, man spiel nicht mit Unterschriften!)
@BerlinerSchule, wenn dann beginnt die Wikipedia-Zeitrechnung am 15. Januar 2001. Als Monatsnamen würden sich die Namen der Mitglieder des WMF-Boards eignen. liesel Schreibsklave®13:27, 27. Okt. 2011 (CEST)[Beantworten]
Im einzelnen habe ich keine Ahnung vom Thema und bei WMF denke ich immer an Cromargan, ohne genau zu wissen, was das heißt. Aber ich teile Deine Zuversicht, dass es da oder dort genug Freiwillige gäbe, die ihren Namen für einen Monat zur Verfügung stellten. BerlinerSchule13:35, 27. Okt. 2011 (CEST)[Beantworten]
aus unerfindlichen Gründen funktioniert bei mir die Bedienung des Template Tigers nicht. Die Syntax mit where= und is= hab ich verstanden, die funktioniert auch (habs an Personendaten ausprobiert). Genau genommen geht es dabei aber um die Infobox Fußballspieler, da ist nämlich ein ß drin, und damit kommt (mein Browser, das Tool, wer auch immer) nicht klar, er schreibt dann nämlich Infobox Fu⍰ballspieler und hat dann für jede Eingabe no entries.
Könnte mir jemand sagen/erklären wie ich das Problem mit dem Fragezeichen/ß löse? Es dankt im Voraus --BayernMuenchen14:20, 27. Okt. 2011 (CEST)[Beantworten]
Ich möchte den Artikel nach "nette Toilette" verschieben, da es sich imho um einen Eigennamen handelt. Da sich die Schreibweise aus Sicht der Software nicht geändert hat, geht das anscheinend nur über die Zwischenstufe einer blödsinnigen Überschrift wie z.B. "Schöne Toilette" oder ähnlichen. Liege ich damit richtig? Gruß vom
--Giftmischer16:41, 27. Okt. 2011 (CEST)[Beantworten]
Die versionsgelöschten dürften NICHT dabei sein, die Benutzeraccountdaten auch nicht. Die Benutzerseiten vermutlich schon (warum auch nicht). --Guandalug17:23, 27. Okt. 2011 (CEST)[Beantworten]
Beim Import (also: Import-upload, kein Dump) auf eine eigene lokale Wiki sind die gelöschten Versionen nicht da und ergo auch nicht wiederherzustellen. -jkb-17:33, 27. Okt. 2011 (CEST)[Beantworten]
Wenn man Versionen per revisiondelete versteckt und die Seite woanders importiert, sind die versionsgelöschten Versionen zwar noch da, aber leer. Beispiel: [4]. Wie es bei einem Datenbankdump aussieht, weiß ich nicht, aber hoffentlich ist es dort genauso. XenonX3 - (☎:✉) 17:41, 27. Okt. 2011 (CEST)[Beantworten]
Es gibt verschiedene Dumps. Der wohl am meistgenutzte Dump umfasst die aktuellen Versionen der Artikel, Vorlagen und Dateibeschreibungsseiten (2,3 GB). Dann gibt es einen Dump der die aktuellen Versionen aller Seiten in allen Namensräume beinhaltet (3,6 GB). Der dritte Seiten-Dump umfasst alle Versionen aller Seiten in allen Namensräumen (111,6 GB). Dann gibt es noch das Logbuch als Dump (1,4 GB). Die 4 genannten Dumps sind alles XML-Dateien. Zusätzlich zu diesen Dateien gibt es noch zu vielen Hilfstabellen SQL-Dumps (pagelinks, templatelinks, imagelinks, categorylinks, Tabellen der gesichteten Versionen, etc.). Die Dumps umfassen die Daten, die auch hier ohne besondere Berechtigungen sichtbar sind. Also keine gelöschten Versionen oder die versteckten Teile von Versionslöschungen. Zusätzlich gibt es keine benutzerbezogende Daten wie Benutzerkonten, Benutzergruppenzuordnung, Benutzersperren, Benutzereinstellungen, Benutzerbeoachtungslisten und keine CheckUser-Daten. Der Umherirrende17:41, 27. Okt. 2011 (CEST)[Beantworten]
Ist es irgendwie möglich, eine Seite "A" gleichzeitig in eine NEUE Kategorie "B" einzuordnen und diese Kaegorie "B" im Quelltext von "A" in eine Kategorie "C" einzuordnen?
Nochmal Klartext: Am Ende will ich A in B in C haben, dazu möchte ich NICHT B aufrufen müssen!
Irgendwie so hab ich mir das gedacht: "[[Kategorie C>Kategorie B]]", aber das ist nur geraten und funktioniert nicht
Ok, gibt es dann wenigstens eine Möglichkeit, mit der ich von Seiten Informationen an Kategorien weitergeben kann? Also eine Variable oder so etwas?
Oder sind die Kategorien dafür ein zu starres Konstrukt?
Immerhin erkennt die Kategorie ja, dass manche Seiten ebenfalls Kategorien sind.
Also generell die Frage: Kann man mit Kategorien mehr machen, als sie sich nur anzeigen lassen?
Zum Beispiel auslesen, wie viele Kategorien mit dem Buchstaben A beginnen und dann mit dieser Information in der Kategorie etwas programmieren?
Dankeschön :)
Es gibt verschiedene Möglichkeiten, mit Kategorie was zu machen. Etwa WP:CatScan. Aber programmieren läßt sich da nicht etwas. Aber vielleicht verrätst du uns, was du eigentlich machen willst, dann kann man a) leichter sagen, was da möglich ist und b) ob das überhaupt sinnvoll ist. --Matthiasb(CallMyCenter)19:11, 27. Okt. 2011 (CEST)[Beantworten]
Ok, danke erstmal dafür, muss mal schauen, ob das klappt. Was ich tue fragst Du. Ich schreibe ein Template und das soll möglichst anwenderfreundlich sein. Am besten wäre es wie gesagt, wenn der Nutzer in "A" nur
eingeben müsste. Davon hab ich mich aber nach Deiner Antwort schon verabschieden müssen. Eine andere Möglichkeit wäre, dass ich "B" komplett entferne, den Nutzer eine Information "xyz" in "A" eingeben lasse, und mit dieser Information in "C" zumindest eine Baumstruktur erstellen kann und dort "B" reinschreiben kann.
Du möchtest also, das der Artikel die Oberkategorie verwaltet? Das geht nicht. Vorallem stellt sich die Frage, wenn in zwei Artikeln verschiedene Oberkategorien stehen, also A -> B -> C und D -> B -> E, dann steht auch A unterhalb von E und D unterhalb von C. Es sollte immer nur die Seite selber die Kategorien eine Stufe nach oben verwalten. Der Umherirrende10:46, 28. Okt. 2011 (CEST)[Beantworten]
theopenglobe.org nutzt auch MediaWiki und bindet die Inhalte direkt von Commons ein. Das ganz nennt sich InstantCommons (hier beschrieben: Commons:Commons:Weiterverwendung#MediaWiki ab Version 1.16.0). Im konkreten Fall wäre es wohl das sicherste, wenn auf Commons:File:United States (orthographic projection).svg im Feld „Author“ auch die Mitautoren eingetragen werden. Nicht jeder Wikipedianer, der eine neue Version hochgeladen hat, ist bei mangelnder Schöpfungshöhe seiner Änderung (hier nicht im Detail geprüft) Mitautor.
Wenn A, B, C und D nacheinander verschiedene Bilder unter dem gleichen Dateinamen hochladen, haben wir drei Vandalen und drei Benutzer, die mit dem gezeigten Bild nichts zu tun haben. Oder anders: Warum sollten wir all die Schmierfinken in der Versionsgeschichte nennen, deren Versuche gelöscht wurden?
Bei verschiedenen Nachbearbeitungen eines Bildes, kommt es auf die Schöpfungshöhe der Änderung an. die verschiedenen Bildbeschreibungen werden ja ohnehin nur direkt auf commons gezeigt und nie im Artikel.
--Eingangskontrolle12:03, 28. Okt. 2011 (CEST)[Beantworten]
28. Oktober 2011
Webseiten mit Interaktivität (SVG)
Auf manchen Seiten findet man Quellen- und/oder Weblinks auf sogenannte Interaktive SVG-Maps, welche - browserabhängig - nicht immer per Javascript sichtbar sind. Um sich diese Inhalte dennoch anzusehen, MUSS ein PlugIn (der Firma Adobe) zwangsläufig installiert werden. Sind solche Verweise daher überhaupt mit dem Grundgedanken einer freien Enzyklopädie vereinbar? --Zollwurf23:58, 27. Okt. 2011 (CEST)[Beantworten]
Ja, sind sie, SVG ist nicht wirklich interaktiv, sondern ein standardisiertes Vektorbildformat und spielt damit in der gleichen Liga wie HTML. Mit JavaScript hat das rein gar nichts zu tun. Das Adobe-Plug-in wird nur von veralteten Browsern (IE<9) benötigt. Die anderen gängigen Browser, die das schon länger können, sowie der IE ab Version 9 können SVG-Dateien nativ darstellen. --StG1990Disk.00:05, 28. Okt. 2011 (CEST)[Beantworten]
Nööö, SVG ist alles andere als problemlos. Das sollte genauso behandelt werden wie JS oder Flash. Freakformat und nicht allgemein unterstützt, von Nachnutzung mal ganz abgesehen. --Marcela00:22, 28. Okt. 2011 (CEST)[Beantworten]
(BK)SVG ist offizieller Standard des W3C und bei weitem kein Freakformat. Auch andere Formate werden nicht allgemein unterstützt. Die Unterstützung ist bei allen modernen Browser, die sich an Webstandards halten gegeben (siehe auch Scalable Vector Graphics#SVG-Unterstützung in Browsern). Nur, weil sich die nicht standardkonforme Software von Microsoft auch mit dem IE9 noch nicht halbwegs annehmbar dazu verhält ist das kein Grund das Format zu verfluchen. Vektorgrafiken haben deutliche Vorteile gegenüber Pixelbildern. Ergänzung nach dem BK: Pixelschubser wie Photoshop oder Gimp können das natürlich nicht einlesen. Dafür gibt es gängige Vektorzeichenprogramme, wie Adobe Illustrator oder Inkscape. Den Illustrator würde ich dabei durchaus auch als gängige Software bezeichnen. --StG1990Disk.00:47, 28. Okt. 2011 (CEST)[Beantworten]
CAD-Programme sind auch eher nicht dafür gedacht Dateien zu erstellen, die für das Internet entwickelt wurden, dafür gibt es eben die anderen Vektorgrafikzeichenprogramme. CAD-Programme und Programme, wie Illustrator oder Inkscape haben recht verschiedene Zielgruppen. Als W3C-Standard ist die Verwendung von SVG jedoch wie gesagt recht wünschenswert. --StG1990Disk.01:16, 28. Okt. 2011 (CEST)[Beantworten]
Ich erzähl dir das nicht zum ersten Mal: Das Format ist verbreiteter als du glaubst, auch in CAD-Bereich. Es gibt (große!) Unternehmen, die fordern, dass Konstruktionspläne etc. in offenen Formaten (=im Vektorbereich SVG) gespeichert werden, es gibt Benutzeroberflächen, die komplett in SVG erstellt werden. Alles Freaks? Oder vielleicht eher Leute, die sich überlegt haben, welches Format sie wofür nutzen? Brauchbare Browser zur Anzeige gibt es jede Menge, Grafikanzeigeprogramme ebenso, Und Gimp kann das SVG zumindest importieren. Ich habe seit 4 Jahren keinen Rechner mehr unter den Fingern gehabt, der nicht von Haus aus irgendein Programm zur SVG-Anzeige an Bord hatte.
CAD-Programme als Referenz anzuführen ist nebenbei deutlich irreführend: Deren Zweck ist es nicht, Vektorgrafiken zu erstellen. Damit werden Konstruktionspläne etc. erstellt. Output: Grafiken (verschiedenste Formate, darunter sowohl Vektorgrafiken als auch Bitmaps) von Werkstücken und Werkzeugen, Animationen, Stücklisten, ...
Nebenbei haben wohl deutlich weniger Leute ein CAD-Programm installiert als ein Programm zur SVG-Anzeige. Was auch nicht verwunderlich ist: Die wollen es ja nur angezeigt bekommen. Den Erstellungsprozess (welches Grafik-Programm wurde genutzt?) zum Maßstab zu machen ist falschrum gedacht: Der Köder muss dem Fisch schmecken, nicht dem Angler.
Ich hab keinen Schmerz, wenn du ein Format nicht magst. Aber eine Argumentation '$MEINLIEBLINGSPROGRAMM kann das nicht, also ist das was für Freaks' ist extrem ärgerlich. Und wenn SVG jetzt Bäh ist, was wäre denn die Alternative? Gar kein Vektorformat mehr im Web? --Gnu174209:05, 28. Okt. 2011 (CEST)[Beantworten]
Mit CAD wurden schon Vektorgrafiken erstellt, lange bevor es die erstem Malprogramme gab, aus dem CAD-Bereich kommt die Vektorgrafik. DXF wäre eine Alternative, das ist zufällig sogar frei, wird von allen Vektorgrafikprogrammen in allen Betriebssystemen unterstützt. Und im Gegensatz zu SVG ist es ein konsequentes Vektorformat. Dinge wie Verläufe haben nämlich nichts mit Vektorgrafik zu tun. --Marcela10:11, 28. Okt. 2011 (CEST)[Beantworten]
Ich weiß, es ist dein Lieblingsthema, aber durch ewiges Nörgeln wird es auch nicht besser. Versuchen wir es mal mit Fakten (einige hatte das Gnu schon aufgeführt):
Erzeugen von Bitmapgrafiken aus SVGs: mit Imagemagick möglich und auf WMF-Servern installiert.
Erzeugen von Bitmapgrafiken aus DXFs: Imagemagick scheint es nicht zu können, welche freien Programme gibt es dafür?
Erstellen von SVGs: Inkscape und andere.
Erstellen von DXFs: AutoCad (teuer!), welche freie oder zumindest preiswerte Software bietet sich hier an?
Unterstützung durch MediaWiki: Keine. Da du schon so lange nörgelst: Wo sind deine Versuche, z.B. durch WMDE eine entsprechende Extension programmieren zu lassen. WMDE hat ja auch die TIFF-Unterstützung in MediaWiki finanziert.
Gibt es die Möglichkeit die Reihenfolge von Suchergebnissen und Spezial:Linkliste und Spezial:Weblinksuche zu beeinflussen? Gerade bei Ergebnissen die die 500 übersteigen ist mit der browserinternen Suchfunktion das Gesuchte zu finden wenig zu machen. Die Ergebnisse scheinen mir in der Linkliste und Weblinksuche eher in einer zufälligen Reihenfolge zu stehen. Alphabetisch wäre mal sinnvoll. Kann ich das irgendwie beeinflussen. Bei der normalenSuche habe ich noch die Möglichkeit durch z. B. intitle:Suchbegriff einen Einfluss zu nehmen, die Reihenfolge scheint mir aber eher nach Jimbos Gutdünken zu erfolgen. --217.246.205.5309:07, 28. Okt. 2011 (CEST)[Beantworten]
Na super, Danke. Der Bug ist erst sechs Jahre eingetragen. Bin mir nicht sicher aber war das immer so mit den Suchergebnissen? Ich meine das mal anders gesehen zu haben. --217.246.205.5309:36, 28. Okt. 2011 (CEST)[Beantworten]
Bei der Linkliste ist die Reihenfolge nach der Artikel-ID. Für die neueren Artikel ist das gleichbedeutend mit einer Sortierung nach dem Zeitpunkt der Erstellung. Wonach die Weblinksuche sortiert, will sich mir irgendwie nicht erschließen. Bei der Suche wird inzwischen ein recht komplexes Verfahren für die Sortierung verwendet, das hier dokumentiert ist. --Schnark09:53, 28. Okt. 2011 (CEST)[Beantworten]
Die Weblinksuche sollte auch in der Reihenfolge der Artikel-IDs sein. Eine alphabetische Sortierung kostet Performance und scheitert in einigen Sprachen auch an den Sortierregeln, die auf Datenbankebene verfügbar sein muss. Der Umherirrende10:41, 28. Okt. 2011 (CEST)[Beantworten]
Die größeren Spitzen sind hier → aktuell 493 Artikel und aktuell ca. 3400 Artikel weil nicht dargestellt wird. Dieses sind nur 2 Ausgewählte Oberkategorien mit entsprechender Vorlageneinbindung - die Artikel dieses Bildes wurden nicht nachgesichtet. Kommen sicher noch tausende andere Artikel hinzu.
Das Problem wird sich wahrscheinlich nur darstellen wenn der User nicht angemeldet ist, denn die Geo-Marker werden bei Permalink bzw. ?stable=0 angezeigt.
Fazit: Nachsichten löst das Problem nicht
Eigentlich ist das eine VM wert, nur gegen wen? Es braucht aber wohl nichts unternommen werden, betrifft nur die größte Benutzerguppe - nicht angemeldete, also IPs (so wie ich). --217.246.219.5716:41, 28. Okt. 2011 (CEST)[Beantworten]
Ich habe zu dem Thema Bug 31962 gefunden. Die Software-Änderungen sind bereits live. Dort steht auch, das ein Purge hilft. Ich habe die Einbindungen der hier genannten Dateien gepurged. Hoffe, das es damit etwas angenehmer wird. Der Umherirrende12:09, 29. Okt. 2011 (CEST)[Beantworten]
Das ist nicht Dein Ernst? Die Geo-Marker hatte ich auch gepurged. Die über 4000 Artikel meinst Du nicht oder die hast du nicht gepurged? Das Problem sollte nachhaltig gelöst werden! Wenn eine Datei auf commons geändert wird darf es nicht zu solchen Fehlern kommen. Lassen wirs dabei bewenden. Habe noch ein paar andere Problemfälle gefunden. Die gibts dann später. --217.246.211.22312:27, 29. Okt. 2011 (CEST)[Beantworten]
Dieser Abschnitt kann archiviert werden. Der Umherirrende 12:09, 29. Okt. 2011 (CEST)
Versionsvergleiche
Wird eigentlich daran gearbeitet, die mal wirklich brauchbarer zu machen? Die roten Hervorhebungen kennzeichnen ja nicht immer tatsächliche Textänderänderungen, sondern auch schlichte Verschiebungen ganzer Absätze. Wobei gelegentlich ohne nachvollziehbaren Grund Teile wiederum schwarz sind. Das macht Vergleiche zuweilen mühsam und ich verstehe die Logik dahinter auch nicht. Rainer Z ...18:26, 28. Okt. 2011 (CEST)[Beantworten]
Hallo Rainer, das behebt zwar nicht das Problem aller Nutzer, die das nicht einbauen/einbauen können (und ich stimme Dir zu, es wäre schön, wenn diese Funktion ohne jetzt-bastel-ich-mir-einen-Knallfrosch für alle automatisch möglich wäre), aber Du kannst Dir das WikEdDiff einbauen (abschreiben von meiner vector.js, erster Eintrag). Oder das Difftool von Schnark (abschreiben von meiner common.js). Das hilft ungemein, wenn man rausfinden will, welches Komma jemand geändert hat. --Schwäbin21:39, 28. Okt. 2011 (CEST)[Beantworten]
Ich hab da einen Fehler gefunden und weiß nicht wohin damit, deshalb stell ich ihn einfach mal hier rein. Wenn man mit der Mobil-Version einen Artikel ändern möchte, kommt ein Fehler:
Da hat jemand mal 'ne Abfrage eingebaut a la {{#ifexist: Media:BSicon ... Das war zwar gut gemeint, sorgt aber nun dafür, dass umbenannte Dateien und generell redirects auf BSicons nicht mehr dargestellt werden. Habe den entsprechende code mal auskommentiert, das muss auch irgendwie anders gehen ... a×pdeHallo!21:23, 29. Okt. 2011 (CEST)[Beantworten]
Ah, deswegen sind vorhin ganz schnell über 200 der verlinkten Artikel verschwunden. Aber um die 30 Artikel hatten weiterhin Probleme mit weitergeleiteten Bildern. Bin gerade dabei, soweit ich komme, die Weiterleitungen manuell aufzulösen (denn BS2/BS3/BS4 hattest du nicht geändert). Aber die Fehlerauswertung sollte irgendwie wieder eingebaut werden. --Quedel22:31, 29. Okt. 2011 (CEST)[Beantworten]
Nö, Benutzer:Spreewasser hatte etwa 70 und Du etwa 25 und ich etwa 135 Artikel aufgelöst. Wer den Rest gemacht hat oder ob es die Vorlage gemacht hat (glaube ich nict, sonst wäre der Rest in Ordnung gewesen bis zu diesem Post) weiß ich nicht. Belibt ein Rest von eins, zu dem es kein/e passende/s Bild/er gibt--Knochen00:59, 30. Okt. 2011 (CEST)[Beantworten]
Den letzten Artikel habe ich nun doch noch erledigt, war gestern zu spät. @Aypde ob Du die Änderung der Vorlage wieder rückgängig machen musst solltest Du mal schauen. Grundsätzlich sollten solche Fehler nicht auftreten, die weitergeleiteten Dateien wurden vor über einem Jahr geändert. Das Problem ist erst mit der neuen Software aufgeschlagen. --Knochen09:39, 30. Okt. 2011 (CET)[Beantworten]
Es war seit langem Praxis, BSicons umzubenennen und die redirect so lange zu behalten, bis alle Verwendungen manuell beseitigt worden sind. Die in {{BS}} eingebaute Prüfung sollte eigentlich nur die Symbole anzeigen, die vollständig entfernt wurden (umbenannt, gelöscht, etc.). Da aber seit der neuen mediawiki Version Weiterleitungen auf Dateien von der Abfrage #ifexist: nicht mehr als Medium erkannt werden, müssen wir uns wohl oder übel etwas anderes einfallen lassen ... Gruß a×pdeHallo!15:07, 30. Okt. 2011 (CET)[Beantworten]
MediaWiki: Sperrbegründungen als Systemnachricht vorgeben
Hallo!
Wie heißt die MediaWiki-Namensraum-Seite, auf der man als Systemnachricht Sperrbegründungen eintragen kann? Ich würde gerne solche Systemnachrichten in einem externen Projekt benutzen, weiß aber leider nicht den passenden MW-Seitentitel. Grüße, Grand-Duc01:35, 29. Okt. 2011 (CEST)[Beantworten]
Danke! :-) (Merke ich mir - ich hatte mich nämlich missverständlich ausgedrückt, ich meinte keine Benutzersperren, sondern Seitensperren. Mittlerweile habe ich aber den praktischen Link "Schutzgründe bearbeiten" bei mir unten rechts im Interface entdeckt, was mich zu der Seite MediaWiki:Protect-dropdown geführt hatte). Grüße, Grand-Duc01:52, 29. Okt. 2011 (CEST)[Beantworten]
Ob das in diesem Fall funktioniert, weiß ich nicht, aber oft hilft es, an die URL ein ?uselang=qqx (bzw. &uselang=qqx, falls es schon andere Parameter gibt) anzuhängen. Dadurch werden statt der Meldungen ihre Namen ausgegeben, sodass man leicht findet, was man wo ändern kann. --Schnark10:38, 29. Okt. 2011 (CEST)[Beantworten]
Login bei anderen Projekten
Wieso bin ich nicht mehr automatisch bei Commons, Meta und anderen Projekten eingeloggt? Die üblichen Verdächtigen wie Cookies und Browsercache löschen helfen nicht. Bei der Anmeldung wird mir aber bestätigt, dass ich bei allen angemeldet wurde. Liegt das evtl. mal wieder am Skin? Ich verwende immer noch monobook. Gruß -- AstrobeamerAsk the CEO01:57, 29. Okt. 2011 (CEST)[Beantworten]
Ich hatte im Firefox die Option "Cookies von Drittanbietern akzeptieren" deaktiviert. Es geht nun wieder. Wieso die anderen Projekte Drittanbieter sind, erschließt sich mir leider nicht. Gruß -- AstrobeamerAsk the CEO02:29, 29. Okt. 2011 (CEST)[Beantworten]
Dieser Abschnitt kann archiviert werden. Quedel 15:49, 30. Okt. 2011 (CET)
Du kannst andere Benutzer darauf hinweisen, dass du diese Änderungen überprüfst.
Dieser Hinweis erscheint mit einem Link bei zu sichtenden Versionen. Was macht denn der Hinweis bzw. der Klick auf den Link? Wo landet der Hinweis? Ich habe es ausprobiert, aber der Effekt war nicht erkennbar (außer, dass ich meinen Hinweis zurücknehmen konnte, was ich dann auch tat). Steht das schon irgendwo erläutert? Wäre in der Hinweis-Box ein "Hilfe"-Link sinnvoll? (Viele Fragen auf einmal, aber heißt es hier nicht Fragen zu Wikipedia? Wäre da eine nicht zu wenig?) Anka☺☻Wau!16:38, 29. Okt. 2011 (CEST)[Beantworten]
Wenn du auf den Link klickst, werden andere Benutzer, die ebenfalls gerade diesen Versionunterschied ansehen, darauf aufmerksam gemacht, dass jemand anderes ebenfalls den Diff anschaut. Gruß, --Inkowik16:55, 29. Okt. 2011 (CEST)[Beantworten]
Was wie bereits anderseits bemerkt, ziemlich sinnlos ist. Mir fällt z.B. manchml in einer zu sichtenden Version ein typo auf, der dan zunächst verbessert wird und dann sichte ich meine neue Version. --Eingangskontrolle18:40, 29. Okt. 2011 (CEST)[Beantworten]
Ich fände es eigentlich recht nützlich, wenn man unabhängig vom Sichten bei einem Artikel markieren könnte, dass man ihn gerade bearbeitet. Sowas sollte sich doch eigentlich recht leicht umsetzen lassen, oder? --Carlos-X22:40, 29. Okt. 2011 (CEST)[Beantworten]
Das wäre tatsächlich ein Fortschritt: "Ein anderer Benutzer hat das Bearbeitenfenster dieses Artikels offen" kann manchmal nützlich sein. Aber wenn zwei User fast gleichzeitig und damit einer unnütz sichtet, ist doch sowas von egal. --Eingangskontrolle01:57, 30. Okt. 2011 (CEST)[Beantworten]
Für dem Einsatz von Inuse ist bei mir die Hemmschwelle relativ groß, ich setze Inuse eigentlich nur bei Bearbeitungen von mehr als 30 Minuten mit realistischem Konfliktpotential. Bei der Eingangskontrolle sind aber meist Bearbeitungen zwischen 30 Sekunden und 10 Minuten zu erledigen, da wirkt Inuse fast so, als ob man zusätzliche Edits schinden wolle. Bei der sonstigen Arbeit müssen nicht unbedingt 50 Leute auf ihrer Beobachtungsliste sehen, wenn ich einen Artikel bearbeiten wollte, es dann aber doch nicht getan habe (z.B. weil ein Anruf kam). --Carlos-X16:16, 30. Okt. 2011 (CET)[Beantworten]
Danke für Eure Antworten, auch wenn ich gestehe, nicht viel schlauer zu sein als vorher. Muss ich mal mit irgendwem zusammen ausprobieren bei Gelegenheit. (Anklicken und gucken, was der andere dann sieht.) Anka☺☻Wau!21:37, 30. Okt. 2011 (CET)[Beantworten]
Aussehen sollte das Ganze so ähnlich wie hier, nur dass ursprünglich die Anzeige, wer gerade sichtet nicht erst durch einen Klick ausgelöst wurde. --Schnark09:23, 31. Okt. 2011 (CET)[Beantworten]
Guckst du viel weiter oben, Abschnitt 1.29. Gehst du auf Commons, findest du ein Icon zum Bilddrehen. Richtest das Bild wie gewüscht. Wartest. Morgen gehst in den Personenartikel, purgst und sichstest und freust dich. --Matthiasb(CallMyCenter)17:07, 29. Okt. 2011 (CEST)[Beantworten]
Danke, aber noch nicht so recht erledigt. Im Wahlkreis-Artikel wurde das Bild seit jeher richtig angezeigt, nur im Personenartikel erschien es gedreht. So einfach, dass es sich einfach um ein noch nicht richtig gedrehtes Bild handelte, ist die Sache nicht. -- Felix König✉18:52, 29. Okt. 2011 (CEST)[Beantworten]
Spamschutzfilter
Hallo, ich bin sicherlich nicht der erste, der dieses Problem hat: der Spamschutzfilter blockiert mir einem Weblink. Leider habe ich nicht so ganz begriffen, wie ich die Internetadresse entsperren lassen kann.
Es geht um den Artikel Hans Fellgiebel. Hier wird mir der Weblink http: // www.hippo-logos.com/main/component/option,com...0/.../gid,55/ blockiert, den ich als Einzelnachweis gerne haben würde (Der Artikel "Fahrkultur, Teil 3: Von der Kulturtechnik zum Sport" ist hier hinterlegt). Könnte mir jemand helfen? Grüße --Nordlicht817:02, 29. Okt. 2011 (CEST)[Beantworten]
Ich kann mich noch erinnern, dass früher (d.h. vor dem MW 1.18-Update) Wikilinks auch direkt im Diff funktionierten. Kann das jemand bestätigen oder ist es ein Problem was außerhalb der WP zu suchen ist. liesel Schreibsklave®23:56, 29. Okt. 2011 (CEST)[Beantworten]
Korrekt, man kann das Diff-Modul aber auch separat einbinden. In Liesels monobook.js ist das offenbar der Fall, zusätzlich ist dort auch Schnarks Diff-Modul enthalten (offenbar als Bestandteil von PDDs Monobook). Ohne eines dieser Module und/oder die Aktivierung von wikEd als Helferlein sind Links in Diffs grundsätzlich nicht klickbar. Beim Diff-Modul von wikEd sind Links klickbar, nach dem MediaWiki-Update hat es bloß für ein paar Tage, maximal Wochen, nicht funktioniert. Theoretisch würde ich sagen „leer mal deinen Cache“, aber da du deine .js ja erst vor ein paar Tagen bearbeitet hast ... Oder hast du den Skin gewechselt? In deiner vector.js ist das ja nicht eingebunden. Gruß --Schniggendiller Diskussion 01:50, 30. Okt. 2011 (CEST)[Beantworten]
In Dateikategorien (Beispiel) werden bei mir nur die ersten 22 Zeichen des Dateinamens angezeigt. Kann ich in meinen Einstellungen oder der benutzerdefinierten CSS- oder JavaScript-Datei Änderungen vornehmen, sodass mehr als 22 – beispielsweise 40 – Zeichen des Dateinamens angezeigt werden? --Ephraim3310:27, 30. Okt. 2011 (CET)[Beantworten]
Das halte ich auch für ein ganz schlechtes Feature von MediaWiki. Allerlei Müll wird in unserem Skin angezeigt, aber nicht die wirklich wichtige Information. --89.247.170.4821:47, 30. Okt. 2011 (CET)[Beantworten]
Jetzt sind se wech. Warum weiß ich nicht. Habe den oberen Abschnitt ausgeschnitten - Vorschau - wieder eingefügt - Vorschau - gespeichert. Wech isset. --Knochen11:16, 30. Okt. 2011 (CET)[Beantworten]
@ Tsor: verstehe nicht was du meinst. Probiere es hier im Abschnitt - schneide das Foto weg und lass da dennoch eine Leerzeile - alles in ordnung. -jkb-11:45, 30. Okt. 2011 (CET)[Beantworten]
Das sind keine leeren Zeilen, sondern Absätze, die das Zeichen U+FEFF (ZERO WIDTH NO-BREAK SPACE) enthalten - genauso wie dieser Abschnitt hier als erstes Zeichen nach der Zwischenüberschrift. Komischerweise wird das Zeichen von meinem Brauser mit dem Fallback-Font dargestellt, obwohl es eigentlich kein druckbares Zeichen ist. --Jumbo143512:02, 30. Okt. 2011 (CET)[Beantworten]
Jetzt kann ich nicht nachvollziehen was du meinst, aber folgendes habe ich entdeckt: die erst anführende eckige Klammer beim Bild war nicht "[" sondern " [ ", wenn mans durch die normale ersetzt, ist alles paletti. -jkb- 12:08, 30. Okt. 2011 (CET) - - - p.s. wird nur im Bearbeitungsmodus sichtbar -jkb-12:09, 30. Okt. 2011 (CET)[Beantworten]
Die Klammer selbst ist unschuldig. Auslöser war das Zeichen U+FEFF, das noch vor der Klammer steht. Zu Demonstrationszwecken habe ich es am Anfang des Absatzes jetzt mal durch das Zeichen U+006D (LATIN SMALL LETTER M, also einfach ein kleines m) ersetzt. Diese Zeichen werden von der Wikisoftware halt für Text gehalten, der angezeigt werden soll. Entsprechend wird vor der Bildeinbindung ein Absatz mit dem Text erzeugt. Und wenn der Brauser nun richtig funktioniert, dann zeigt er beim Zeichen U+FEFF halt einen Absatz, der nur einen Leerzeichen mit der Breite 0 enthält, also optisch eine Leerzeile an. --Jumbo143513:44, 30. Okt. 2011 (CET)[Beantworten]
Benutz mal oben die Suche. Antwort immer wieder: dann, wann es passiert. Das kann innerhalb Tagen sein, manchmal sind die Artikel aber auch nach Wochen oder vielen Monaten (oder noch länger) nicht da zu sehen. Kommt halt ganz drauf an, wie Google Lust hast. Dabei ist eigentlich alles egal, die Popularität, die Seitenzahlaufrufe, die Interwikilinks, die Artikellänge, die Kategorie - bisher kein Muster erkennbar. Wenn ich mich recht erinnere waren 3-4 Wochen mal das schnellste gewesen was jemand berichtet hat. --Quedel15:57, 30. Okt. 2011 (CET)[Beantworten]
Ergänzung, ein Artikel von mir vom 1. Mai ist drin, vom 20. Juli nicht (dazwischen hatte ich nichts Geocodiertes). Auch sonst rechne ich eher mit 1/2 Jahr als mit 3-4 Wochen. --bjsMS20:58, 31. Okt. 2011 (CET)[Beantworten]
Dieser Abschnitt kann archiviert werden. alofokIch mag Kekse! 12:23, 31. Okt. 2011 (CET)
Gute Frage. Beim Portal? Oder selber machen? Auf der Disk steht, welche Seite nachgepflegt werden muss, damit der Bot das mitbekommt. --Guandalug17:46, 30. Okt. 2011 (CET)[Beantworten]
Ich glaube der Bot der das pflegt ist das geringere Problem. Wichtiger ist ein Bot der verschiebt und die Links auf den Seiten entsprechend anpasst. liesel Schreibsklave®18:04, 30. Okt. 2011 (CET)[Beantworten]
Wenn du so fragst: Heiße Luft. "Will kaufen" ist uns ziemlich egal, denn die Kaufabsicht ist nicht enzyklopädisch wertvoll. "Hat gekauft" mit Quelle ist was anderes, aber die Glaskugelei einer Absichtserklärung? (Alles meine Meinung, natürlich) --Guandalug17:07, 30. Okt. 2011 (CET)[Beantworten]
Wird auch von Merlbot auf den Wartungsseiten der jeweiligen Projekte eingetragen, so dass das nicht nur zentral abgearbeitet werden muss, sondern auch von den Fachprojekten erledigt werden kann. --bjsMS10:43, 31. Okt. 2011 (CET)[Beantworten]
Gleiche Namen
Wenn Vor- und Nachname eines neuen biografischen Artikels schon vergeben sind, gehört ein Klammerzusatz zum neuen Artikel. Klar. Hinweis {Dieser Artikel|...} oder BKL auch klar. Aber wie verfahre ich mit dem Lemma des vorhandenen Artikels? Lassen oder mit Klammerzusatz verschieben?--Mehlauge21:44, 30. Okt. 2011 (CET)[Beantworten]
Das kommt darauf an, wie die "Wichtigkeit" der beiden Personen im Vergleich aussieht. Wenn beide ungefähr gleich relevant oder irrelevant sind, dann sollten beide eine Klammer bekommen, wenn nicht, nur der "unwichtigere". Steht aber alles bei Wikipedia:Begriffsklärung --89.247.170.4821:49, 30. Okt. 2011 (CET)[Beantworten]
Dieser Abschnitt kann archiviert werden. Schnieke, Schnigge! --NirakkaFeedback? 12:43, 31. Okt. 2011 (CET)
31. Oktober 2011
Aufruf der Signatur
Hallo, seit gestern kann die Signatur nicht mehr aufgerufen werden. Nur per c&p aus einer alten Signatur kann eine Bearbeitung noch ordnungsgemäß beendet werden. Liegt das an meiner PC-Einstellung oder? Gruß,
Wenn am Ende über den Link "Spitze eines Kugelschreibers - in der oberen Zeile, die mit F und K beginnt und mit "Hilfe" endet, die Signatur (mit Uhrzeit/Datum) angeklickt wird, wird dieser Befehl (ohne eine Fehlermeldung) nicht ausgeführt.
Auch jetzt kann diese Notiz nicht ordnungsgemäß mit der Signatur beenden werden ---- ( das Ende wird deshalb über "--" der PC-Tastatur und "4 x ~" der Sonderzeichen eingegeben!), Gruß, --Urdenbacher14:19, 31. Okt. 2011 (CET)[Beantworten]
Von den anderen Symbolen funktionieren "F", "K" und "Sonderzeichen" nicht, aber "Erweitert" und "Hilfe". Rest ?. Betriebssystem: MS Windows xp, home edition, Browser: MS. Gruß, --Urdenbacher16:12, 31. Okt. 2011 (CET)[Beantworten]
Wenn Du im Browser oben in der Menüleiste auf ? klickst und dann auf Info siehst Du welche Version Du hast Internetexplorer X. Gab es irgendwelche updates oder hast du Spezial:Einstellungen oder Einstellungen an Deinem Browser vorgenommen? Evtl hast Du Scripts deaktiviert [8] --Knochen16:55, 31. Okt. 2011 (CET)[Beantworten]
Browser: Internet Explorer 8, rufe aber WP über "AOL" auf. Habe vorher nur, wie alle 8-10 Tage, im Wartungsprogramm von Windows "Speicherplatz freigeben / offene Programme gelöscht". Gruß, --Urdenbacher17:59, 31. Okt. 2011 (CET)[Beantworten]
HMM, verwende den IE nur gelegentlich und dann nicht von anderen Anbietern. Mach mal Extras - Internetoptionen - Allgemein - Browserverlauf - löschen - im neuen PopUp die obersten 4 Haken setzen - löschen - OK klicken. Ist im Prinzip das komplette leeren des H:Cache. Browser schließen und neu öffnen --Knochen18:32, 31. Okt. 2011 (CET)[Beantworten]
Na ja, Fachbegriffe lassen sich sowieso nicht einfach wortwörtlich übersetzen - und häufig lassen sie sich nur aufwendig paraphrasieren, indem man den ganzen Bedeutungskontext mitliefert. Dazu braucht man dann eine Menge Fach- und Sprachwissen, mehr jedenfalls, als ich im speziellen Fall mitbringe (und Du offenbar auch). Gruss --Port(u*o)s15:29, 31. Okt. 2011 (CET)[Beantworten]
Dieser Abschnitt kann archiviert werden. --Vammpi 16:57, 31. Okt. 2011 (CET)
Verlinken zwischen Artikeln
Wenn ich von einer Seite A auf einen Teil "Form" der Seite B verlinken möchte, mach ich das ja so: [[B#Form]]
Wenn ich nun aber der Artikel B der Art
Das setzt immer voraus, dass es sich um "stabile" Artikel handelt, wo wenig - und die Überschriften schon gar nicht - geändert wird. Daher, wenn man schon unbedingt auf Artikelteile verweisen will (ist nicht optimal), ist ein Anker häufig sicherer. -jkb-15:40, 31. Okt. 2011 (CET)[Beantworten]
Das klingt schonmal alles ganz gut. Leider bräuchte ich eher einen "Hauptanker", den ich irgendwie über [[B#Apfel#Form]], oder etwas ähnliches erreichen könnte. Der Artikel B soll nämlich von sehr vielen verschiedenen Nutzern umgeschrieben werden und wenn da jedes Mal ein Anker gesetzt werden muss, dann wird mein Programm nicht genutzt ;).
Willst du etwa auf Stellen verweisen, die es noch gar nicht gibt und die, wenn sie kommen, dann noch geändert werden? Hm, MediaWiki ist eine gute software, aber soooo auch nicht. -jkb-16:03, 31. Okt. 2011 (CET)[Beantworten]
Ja, die Seite existiert schon, aber eben noch nicht alle Unterkapitel. Also es geht sicher irgendwie zu programmieren. Einen Hauptanker bauen, der Text ausliest und dann, wenn genauso viele "öffnende", wie "schließende" "="-Zeichen gekommen sind, den Standardanker mit bestimmten Namen hinsetzt. Das heißt, dass das ganze dann wohl eine Vorlage werden muss, oder kann man anders programmieren?
Mein Problem ist vor allem das erwähnte Lesen des Textes :/.
Eine Erklärung zu anchorencode findest du unter WP:VAR#Funktionen. Ein Browser kann immer nur zu Elementen springen, die eine id (Identifikator) haben. Daher wird hier ein leeres span-Element mit einer ID erzeugt, zu der der Browser dann springen kann. Überschriften haben genauso ein Element, was aber normalerweise den Text der Überschrift als Inhalt hat. Aus Kompatibilätsgründen werden hier zwei Ids erzeugt, einmal wie man es angibt und beim zweitenmal mit vorangestelltem "Anker:". Der Umherirrende18:01, 31. Okt. 2011 (CET)[Beantworten]
Das Feature ist übrigens in Mediawiki schon enthalten. Der erste Anker erhält den Namen des Abschnitts, die folgendenen werden fortlaufend nummeriert (also Form, Form_2, Form_3, ...). --Steef38918:11, 31. Okt. 2011 (CET)[Beantworten]
Aus urheberrechtlicher Sicht spricht nichts dagegen. Allerdings ist der Benutzer per mail erreichbar, d.h. im Sinne einer gedeihlichen und fairen Zusammenarbeit solltest Du zuerst mal per mail anfragen. --tsor17:12, 31. Okt. 2011 (CET)[Beantworten]
Könnte man einen solchen User sperren [Kein Wille zur enzyklopädischen Mitarbeit...] oder gibt das unser Regelwerk nicht her, bzw. ist ein solcher Acc völlig okay? --92.202.53.18417:07, 31. Okt. 2011 (CET)[Beantworten]
Ich vermute mal, die IP meint, dass das nur Beiträge auf Diskussionsseiten sind. Sowas wird schon mal als "Diskussions- oder Laberaccount" bezeichnet. Ich vermute mal, gesperrt wird nur dann, wenn die Person einen Admin nervt ;) Ob eine Enzyklopädie durch Diskussionsbeiträge vorangebracht wird, hängt ja vom Inhalt selbiger ab, aber in der Tendenz könnte man da schon ein "Kein Wille zur enzyklopädischen Mitarbeit" konstruieren (häufig genannter Routinesperrgrund) --SchallundRauch18:10, 31. Okt. 2011 (CET)[Beantworten]
Das hat mal in erster Linie etwas mit Schutz vor unerlaubtem Zugriff zu tun. Solltest Du deinen PC oder Browser ohne jeglichen Kennwortschutz versehen haben, kann jeder der Zugriff darauf hat, (berechtigt oder nicht berechtigt Einbruch, Diebstahl) sich auf Deinem Account einloggen und unter Deinem Namen editieren. Solltest Du von einem Firmenrechner editieren, wäre Dein Chef evtl. berechtigt, ohne Dein Wissen, diesen Rechner zu verwenden und könnte also auf Deinem Account editieren. So ist zumindest nach 30 Tagen ein erneutes eingeben des Kennworts erforderlich. Persönlich habe ich meinen Browser so eingestellt, dass ich mich jedes mal, wenn ich den Browser starte, mit dem Kennwort neu anmelden muss. Da Dein Kennwort bei dem Zugang über http://de.wikipedia.org/ unverschlüsselt übertragen wird, ist das Risiko des ausspähen der Daten recht hoch. Daher sollte, zumindest beim Gebrauch von fremden Rechnern, der Zugang über eine sicher Verbindung (https://de.wikipedia.org/) verwendet werden. (In diesem Fall (und bei Firmenrechnern) sollte man sich vor Beendigung der Sitzung auf jeden Fall abmelden.) Dieses Risiko wird hierbei zumindest minimiert. Das regelmäßige ändern von Kennwörtern im Internet und zu sensibelen Accounts (Bank, etc.) ist selbstverständlich - oder? Siehe Internetkriminalität, Phishing, Informationssicherheit, Netzwerksicherheit usw. --Knochen21:03, 31. Okt. 2011 (CET)[Beantworten]
Da die Diskussion überschaubar ist, hier ein Fullquote: „der Dativ ist dem Genitiv sein Feind. Sprich, Lemma im falschen Fall. Peinliche Sache das“
Da fragt man sich mit welchem Fall die Präposition „von“ verwendet werden soll, wenn nicht mit dem Dativ. Möglicherweise möchte man hier eine Genitivform ohne „von“ wählen. Darüber könnte man nachdenken, Vorteil der völlig korrekten und in diesem Fall nicht umgangssprachlichen, sondern standardsprachlichen von/Dativ-Variante ist aber die Beibehaltung der Grundform des Ortsnamens.--Diwas 21:04, 21:08, 31. Okt. 2011 (CET)[Beantworten]
Das ginge zwar auch. Ist aber nicht so schön, da es den Titel noch länger macht. Oder geht es Dir um die sprachliche Richtigkeit? Die jetzige Variante mit „von“ ist völlig korrekt, wie Diwas oben schon schrieb. --Turpit21:42, 31. Okt. 2011 (CET)[Beantworten]
Klimatabellen werden in Buchfunktion nicht angezeigt
Ich habe gerade versucht mir mittels Buchfunktion eine pdf-Datei von einigen Stadtartikeln zu erstellen. Die Klimatabellen werden hierbei in der pdf gar nicht oder nur mit Fehlern angezeigt. Weiß jemand woran das liegt und wie das behoben werden könnte? (Ich versuch's hier, da für mich Hilfe Diskussion:Buchfunktion ziemlich tot aussieht. Gruß, --Paramecium20:03, 31. Okt. 2011 (CET)[Beantworten]
(CallMyCenter) 11:11, 6. Okt. 2011 (CEST)
.jpg?lang=de)
M S 10:06, 8. Okt. 2011 (CEST)
der Fehler <imagemap>-Fehler: Bild ist ungültig oder nicht vorhanden angezeigt. Angemeldet wird es richtig angezeigt. Wo liegt der Fehler? --Fomafix 11:05, 23. Okt. 2011 (CEST)
--217.246.197.201 15:00, 25. Okt. 2011 (CEST)
00:22, 28. Okt. 2011 (CEST)
nicht dargestellt wird - trotz Nachsichtung. Dieses ist allerdings nur eine kleine Spitze des Eisbergs.
verweisen, weil die eigentliche Datei nicht gefunden wird. Im ersten Fall Bergbahn Lauterbrunnen–Mürren hätte die Datei:BSicon leer.svg bzw. deren Weiterleitung Datei:BSicon .svg eingebunden werden sollen. Im dritten Fall Weschnitztalbahn hätte Datei:BSicon xENDEe.svg bzw. desen Weiterleitung Datei:BSicon ENDExe.svg eingebunden sein sollen - usw. Problem bereits bekannt? Wenn ja dann den nicht Archivierungsbaustin entfernen --Knochen 00:04, 29. Okt. 2011 (CEST)
--Schniggendiller Diskussion 01:59, 30. Okt. 2011 (CEST)
und die anderen „Vector-Icons“ gibt es in der Commons:Category:WikiEditor toolbar icons. Gruß --Schniggendiller Diskussion 23:45, 30. Okt. 2011 (CET)
--Schniggendiller Diskussion 23:51, 30. Okt. 2011 (CET)
.jpg?lang=de){kind=link}
.svg){kind=link}
.svg?lang=de){kind=link}
