Hilfe Diskussion:Bilder/Archiv/2
Dieses Diskussionsarchiv hat die empfohlene Seitengröße erreicht und gilt damit als abgeschlossen. Sein Inhalt sollte nicht mehr verändert werden (ausgenommen Kleinbearbeitungen wie Link- und Vorlagenfixe). Verwende für die Archivierung von Diskussionsbeiträgen bitte das aktuelle Archiv und benutze bitte für aktuelle Diskussionen die aktuelle Diskussionsseite.
Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise
[[Hilfe Diskussion:Bilder/Archiv/2#Abschnittsüberschrift]] https://de.wikipedia.org/wiki/Hilfe_Diskussion:Bilder/Archiv/2#Abschnittsüberschrift |
- 2007 -
Bildname existiert doppelt
Hallo, habe gerade ein Bild auf Commons geladen, und wenn ich es hier einbinden will, kommt ein anderes Bild, das nicht auf Commons liegt und gleich heißt
wie mache ich es, dass das Bild aus Commons benutzt wird, außer das Bild zu verschieben? --androl 16:09, 13. Jan. 2007 (CET)
- entweder das Bild auf Commons unter anderem Namen neu hochladen (Bilder kann man nicht verschieben) oder das hiesige Bild unter anderem Namen in Commons übertragen. Ersteres geht schneller, zweiteres wäre wünschenswerter. Im ersten Fall beim alten Bild einfach die Vorlage commons:Template:Bad name einfügen. --BLueFiSH ✉ (Langeweile?) 16:12, 13. Jan. 2007 (CET)
- danke, habe das Bild jetzt nochmal hochgeladen. --androl 16:31, 13. Jan. 2007 (CET)
externes Bild einbinden
Wie kann ich in einem Wiki ein Bild verlinken und anzeigen lassen, das nicht in einem Namensraum sondern extern liegt? [Bild:http://....jpg%7C120px%7Cthumb%7Cleft%7CBildunterschrift] funktioniert nicht... (nicht für WP, sondern für eigenes Wiki) Danke, --84.147.130.167 11:23, 21. Jan. 2007 (CET)
Imagemap bei SVG
Kann es sein das imagemap bei svg nicht funktioniert? ich habs grad mal probiert hier mein code: <imagemap> Image:Nuclear_power_worldwide-de.svg|600px|Kenrkraftanlagen weltweit poly 469 148 510 144 541 166 543 158 574 165 607 231 624 227 591 274 630 320 618 343 561 369 533 375 512 317 517 293 505 251 458 250 432 215 435 183[[Liste der Kernkraftwerke#Afrika]] default [[Ozean]] desc bottom-right </imagemap>
die Koordinaten hab ich ermittelt indem ich das svg in der vorschau als png grafk gespeichert hab und dann in nem grafikprogramm mit dir x-y-koordinaten raus geucht habe --Devil m25 20:11, 10. Feb. 2007 (CET)
Bilder verdecken manchmal Text
Es ist mir jetzt schon öfter vorgekommen (habe das nach Möglichkeit korrigiert) – z.B. Artikel Relativität- dass die Bilder Teile des umgebenden Textes verdecken (jedenfalls in meinem Mozilla Firefox-Browser). Es ist dann mehrfaches Ausprobieren nötig und Einfügen von Leerzeilen, die spätere Editoren dann u.U. wieder entfernen. Ich finde ein Hinweis wäre in der Hilfe angebracht.
-- Claude J 08:48, 27. Feb. 2007 (CET)
- Bei meinem Browser kommt sowas auch hin und wieder vor, nachdem ich die Seite jeweils noch einmal neu geladen habe passen die Bilder--Vux 22:15, 26. Mär. 2007 (CEST)
subst:Absatz
Wie funktioniert subst:Absatz genau?
Fügt es einfach nur <br clear="all" /> ein?
--TobiWanKenobi 16:11, 5. Mär. 2007 (CET)
Gallerie-Parameter
Irgendwie wollen die nicht funktionieren. Wenn ich wie folgt die Gallerie aufrufe
so überdeckt sich die Einrahmung der einzelnen Bilder mit der Einrahmung der Gallerie oder sie sprengt sie (zumindest in Firefox). Wo ist der Fehler? -jkb- ✉ 21:51, 26. Mär. 2007 (CEST)
- Wo der Fehler ist weiß ich leider nicht, aber im IE6 schauts ok aus. Siehe hier. Gruß, -- McFred 22:14, 26. Mär. 2007 (CEST)
Stimmt, IE tut das komischerweise nicht, doch der bessere (!!!) Firefox ja... -jkb- ✉ 10:43, 27. Mär. 2007 (CEST)
Farbiger Rahmen (Schwarzer Rahmen)
In Ausnahmefällen kann ein farbiger Rahmen (z.B. schwarz) um ein Bild erforderlich sein. Auf die Hilfeseite? -- Matt1971 ⌘ ±⇄ _ ✈_ 17:35, 16. Apr. 2007 (CEST)
- mit dem Codebatzen meiner Ansicht nach nicht. --BLueFiSH ✉ (Langeweile?) 09:20, 17. Apr. 2007 (CEST)
Bilder in Galerien mit eigenem Link versehen
Dieses Szenario ist interessant bei Teaser-Galerien, d.h. Bildern die einen dahinterstehenden Artikel in einem Artikel mit entsprechener Bildunterschrift anteasern. Dort ist es derzeit so, dass die BU mit dem Artikel verlinkt werden kann - das Bild jedoch nicht (verweist auf internen Link Bild:...). Wäre es hier nicht Interessant die Möglichkeit zu geben, das Bild ebenfalls eigens zu verlinken - zumal es dann ja auf der dahinterstehenden Artikelseite erneut erscheint? Ich habe versucht dies mit der Imagemap Vorlage zu realisieren - diese funktionieren jedoch leider nicht in der Galerie. - Andreas von Oettingen 11:41, 22. Apr. 2007 (CEST)
Problem mit SVG-thumbs
Ich habe nun schon 2 SVG-Bilder auf Commons hochgeladen und in die jeweiligen Artikel eingebunden. Da die SVGs natürlich viel zu groß sind, habe ich sie mit thumb verkleinert. Jedoch wird danach leider nur noch der leere Rahmen angezeigt; das Bild ist verschwunden. Wo liegt das Problem?
Bei den Artikeln handelt es sich um:
Bei den Bildern handelt es sich um:
--Ph. Immel 21:11, 24. Apr. 2007 (CEST)
- Verschoben nach WP:RB --Ph. Immel 13:18, 29. Apr. 2007 (CEST)
Problem mit Imagemap in IE
Ich kann in IE Imagemaps nicht klicken, jedenfalls nicht den "default"-Bereich. Zu sehen ist das auf der Beispielkarte im Bereich "Ozean" (Link erscheint unten, klick bewirkt aber nichts) oder auch bei den Bapperln Lesenswert, Exzellent usw. sowohl oben als auch unten. Das Problem dürfte neu sein und tritt nur im IE auf, unter Firefox gehts --schlendrian •λ• 12:26, 17. Mai 2007 (CEST)
- Kann ich mit dem IE7 unter WinXP bestätigen. Wenn ich übers Wochenende eine Lösung finde, patche ich Imagemaps, ansonsten werde ich eine Bugmeldung eröffnen. --Raymond Disk. Bew.
- danke --schlendrian •λ• 15:48, 18. Mai 2007 (CEST)
Senkrechtes Bild
Hallo,
wie kann ich ein senkrecht gehaltenes Foto in der Wikipedia in die Vertikale bringen, so dass eine Person zum Beispiel steht und nicht liegt? --Alexander Bock 15:03, 28. Mai 2007 (CEST)
- Ganz einfach :-): downloade es auf Dein PC, drehe es mit irgendeinem Programm, das so was tut, und uploade es wieder hierher (am besten mit einem neuen Namen). Fertig. -jkb- ✉ 15:08, 28. Mai 2007 (CEST)
Breite x Höhe
Ich hatte letzte Woche diesen Absatz gelöscht:
- Es ist auch möglich, eine Maximalhöhe festzulegen. Wird etwa als Größe
100x200px
angegeben, wird das Bild so skaliert, dass es in einem gedachten Rechteck von 100 Pixel Breite und 200 Pixel Höhe Platz findet. Das Seitenverhältnis bleibt dabei in jedem Fall erhalten.
Ich bin der Meinung, dass dies nicht (mehr) funktioniert. Nun hat jemand anderes mich in diesem Punkte revertiert. Ich verstehe aber nicht, wann und wie diese Syntax zu dem beschriebenen Ergebnis führen soll. Es wird meiner Beobachtung nach immer nur der erste Parameter als Breite genutzt und das Bild dann in dieser Breite dargestellt, die Höhe entsprechend skaliert.
In den letzten Wochen hatte ich mich mit dem MediaWiki-Programmcode beschäftigt und u.a. die neuen Parameter upright, border eingebaut. Auch meine Codeanalyse kam zu keinem anderen Ergebnis. Der Parser holt sich zwar aus … |100x200px| … die Breite x Höhe heraus, der Linker berücksichtigt jedoch in der Funktion makeImageLinkObj die übergebene Höhe nicht weiter.
Eventuell ist dies ein Bug, mir will jedoch auch der Sinn dieser Funktion nicht ganz einleuchten. Was habe ich übersehen? Kann jemand ein Beispiel geben für eine Anwendung? --Raymond Disk. Bew. 07:45, 29. Mai 2007 (CEST)
- Aus meiner sicht hat dies in etwa die gleiche Wirkung wie upright, nur dass ich dabei zusätzlich die Größe steuern kann. Siehe die Proben in Benutzer:-jkb-/Test4 (permalink [1]), wo ich dies mit diversen Werten eingab. -jkb- ✉ 08:39, 29. Mai 2007 (CEST)
- Ich hatte das "100x200px" früher ursprünglich mit "x200px" oder "1x200px" getestet. Meine ursprüngliche Formulierung des Absatzes wurde wohl zwischenzeitlich umformuliert. Solltet ihr also mit "x200px" oder "1x200px" nochmal testen. Gruß --BLueFiSH ✉ (Langeweile?) 12:21, 29. Mai 2007 (CEST)
- wenn ich "x200px" oder "1x200px" eingebe, kommt nur Unsinn raus, nämlich nix. Jedenfalls bei mir. -jkb- ✉ 14:28, 29. Mai 2007 (CEST)
- Kann auch sein, dass es "1000x200px" war, da wurde dann nur die Höhe beachtet. "x200px" ging damals aber auf jeden Fall. --BLueFiSH ✉ (Langeweile?) 10:22, 31. Mai 2007 (CEST)
- Danke für deine Beispielseite. Irgendwie bewirkt diese Syntax also doch was, werde ich nochmal in den Programmcode absteigen um es zu verstehen. --Raymond Disk. Bew. 20:28, 29. Mai 2007 (CEST)
- Hallo Raymond, ich war derjenige, der dich teilrevertiert hat. Ich verwende die Größenangabe "<width>x<height>px" in Vorlage:Infobox Berg und z.B. am Artikel Cerro Torre kannst du sehen, dass es funktioniert. Bilde mir allerdings ein, mich daran erinnern zu können, dass "x<height>px" auch bei mir nicht funktioniert hat. --Herzi Pinki 22:01, 29. Mai 2007 (CEST)
- Ich weiß, dass du mich revertest hast ;-) Danke auch dir für den Hinweis auf diese Infobox. Gibt mir ein weiteres Beispiel zur Analyse. Ich bin immer noch nicht sicher, ob es sich um einen Bug oder ein Feature handelt. --Raymond Disk. Bew. 22:12, 29. Mai 2007 (CEST)
- ... a bug or a feature - this is a question ... :-) :-) -jkb- ✉ 22:34, 29. Mai 2007 (CEST)
- Habe kein weiteres Beispiel, aber Benutzer:-jkb-/Test4 zeigt doch ganz gut, dass es funktioniert. ("1x200px" ist natürlich eine sinnlose Angabe, da ein Bild der Breite 1px nicht wirklich sichtbar ist). --Herzi Pinki 23:16, 29. Mai 2007 (CEST)
- Wie schon oben gemutmasst, nehme ich an, dass dies das gleiche tut wie upright; während upright bei Thumbs benutzt wird, also vermutlich einen gedachten Recheck 180x180px annimt, ist dies für normale Bilder mit wählbaren Parametern von Interesse. Ein gestandener Developer bin ich jedoch keineswegs :-) - -jkb- ✉ 23:21, 29. Mai 2007 (CEST)
- upright habe ich entwickelt und programmiert. Die Funktionsweise ohne weiteren Parameter ist ganz einfach: Es wird die Standardbreite (180px) bzw. die vom Benutzer eingestellte Breite mit 0,75 multipliziert. Daraus ergibt sich immer ein Hochformatbild, das abhängig von den Benutzereinstellungen proportional einem Querformatbild angepasst ist. Man kann upright auch noch einen Paramter mitgeben: z.B. upright=0.5, was für sehr schlanke Hochformatbilder nützlich ist. Auch umgekehrt kann man es nutzen: upright=1.5 dehnt z.B. ein (Querformat-)Bild, z.B. kleinere Panoramen. Der Riesenvorteil ist eben, dass man keine feste Pixelzahl angeben muss, denn mit fest Pixelzahl erfolgt keine automatische benutzerabhängige Skalierung. Die Proportionen bleiben immer erhalten. --Raymond Disk. Bew. 23:47, 29. Mai 2007 (CEST)
- finde ja den neuen Parameter "upright" ausgesprochen nützlich, wenn man weiß, dass es sich um ein Hochformatbild handelt. Aber im Allgemeinen weiß man das ja nicht (z.B. in Infoboxen). Und Infoboxen haben meist eine feste Breite, die durch die Tabelle definiert ist. lg --Herzi Pinki 00:14, 30. Mai 2007 (CEST)
- Ja, Infoboxen sind in dieser Hinsicht ein Sonderfall. --Raymond Disk. Bew. 12:14, 31. Mai 2007 (CEST)
- Upright finde ich auch sehr nützlich. Wo es mir auffällt oder es gebraucht werden kann, setze ich es ein. Kürzlich konnte ich dadurch in Potsdamer Platz die 150px-Größen für die Hochhäuser damit ersetzen. prima. --BLueFiSH ✉ (Langeweile?) 10:22, 31. Mai 2007 (CEST)
- Freut mich, dass der Parameter angenommen wird :) Im übrigen muss die Syntax 100x200px doch ein Feature sein, da ganz aktuell in Bug 7049 diese Syntax auch von Brion, dem Chefentwickler, angesprochen wurde. --Raymond Disk. Bew. 12:14, 31. Mai 2007 (CEST)
- Ich finde die Neuigkeiten ebenfalls sehr nützlich - laufend hat jemand diverse Bilder mit festen Px-Zahlen versehen (und tut es nachwievor). Bei Infoboxen muss man eben darauf verzichten, man kan nicht alles haben. -jkb- ✉ 14:36, 1. Jun. 2007 (CEST)
- 2 (theoretische) Anmerkungen:
- im Englischen heißt es üblicherweise "portrait" (Gegensatz: "landscape") nicht "upright" (soll jetzt aber nicht heißen, dass ich diese Änderung vorschlage)
- Es wäre doch auch denkbar, die Größe in Pixel bei einem thumb immer als Maximalgröße in beiden Dimensionen zu betrachten, das Bild wird ja ohnehin immer proportional skaliert, nie verzerrt. Dann würde eine Angabe (150px, oder 2000px bei großen Panoramen und schlanken Türmen) reichen, weder "upright" noch 100x200px wären notwendig. Irgendein Stück Software auf dem Server sollte doch wissen, ob das Bild nun 100x200px oder 200x100px groß ist, Quer- oder Hochformat. Und alle Hochformate ohne explizite Größenangabe wären plötzlich so formatiert, wie sie nach Hinzufügen von upright formatiert werden. Aber auch hier kann ich die globalen Auswirkungen einer solchen Änderung nicht abschätzen und belasse es gerne bei einer theoretischen Überlegung.
- --Herzi Pinki 20:22, 1. Jun. 2007 (CEST)
Beschreibund totzt Imagemap?
Ist es möglich trotz klickbarem Bild eine Beschreibung des Bildes anzuhängen? -- Widescreen ® 17:02, 3. Jun. 2007 (CEST)
- Meinst du so etwas? --TM 15:14, 11. Jun. 2007 (CEST)
<imagemap>
Bild:Dateiname.jpg|thumb|Beschreibung
…
</imagemap>
bild aus eng. wikipedia in deutscher anzeigen
hab gerade alle möglichen variationen probiert, aber irgendwie bekomme ich es nicht hin, dieses bild: http://en.wikipedia.org/wiki/Image:Vaniity_2006.jpg anzeigen zu lassen :( kann mir jemand dafür den code geben, damit ich es in den artikel setzen kann
oder <a href="http://upload.wikimedia.org/wikipedia/en/9/96/Vaniity_2006.jpg"><img src="hhttp://upload.wikimedia.org/wikipedia/en/9/96/Vaniity_2006.jpg" width="200" height="150"></a>
tanx a lot Bunnyfrosch 21:53, 20. Jun. 2007 (CEST)
- Das ist nicht möglich. Um Bilder hier einzubinden, müssen sie entweder hier oder nach Commons hochgeladen werden. Bei deinem Wunschbild rate ich aber dringend davon ab, da es mir ganz gefährlich nach einer Urheberrechtsverletzung aussieht. Auf der englischen Bildbeschreibungsseite ist eine ganz vage und nicht nachprüfbare Lizenz angegeben. Diese wird weder hier noch auf Commons akzeptiert. --Raymond Disk. Bew. 23:40, 20. Jun. 2007 (CEST)
ok tanx Bunnyfrosch 17:26, 21. Jun. 2007 (CEST)
Analog zu "upright"
Könnte man analog zu "upright" nicht auch einen Parameter einrichten, der sehr breite Bilder (etwa Panoramen) auf eine akzeptable Größe skaliert, analog zu upright, das hochkante Bilder kleiner skaliert? Dann würde man sowas verhindern können --schlendrian •λ• 21:48, 11. Jul. 2007 (CEST)
- "upright" skaliert alle thumbs. Man kann auch einen Faktor größer 1 angeben. Ich habe das mal in Münster an der angegebenen Stelle entsprechend geändert. -- Smial 22:00, 11. Jul. 2007 (CEST)
- Stimmt, interessant. Nächstes Mal lese ich die Seite erst ;-). Danke, --schlendrian •λ• 22:16, 11. Jul. 2007 (CEST)
Lemma
Schlage Verschiebung nach Hilfe:Illustration vor, da es hier nicht nur um Bilder geht (Anlaß: meine Formulierung [Diese Seite erklärt, wie du Bilder] , Grafiken und Karten in Artikel einfügst). -- Bilderwelt 23:06, 18. Jul. 2007 (CEST)
- Der Befehl heißt nun einmal
[[Bild:…]]
. Das sollte einheitlich sein, sonst findet diese Seite hier niemand. --TM 10:27, 19. Jul. 2007 (CEST)- Ja, der Befehl heißt so. Die Auswirkungen auch, nämlich eine Bilddatei. Bloß: Das Ergebnis, also der Inhalt, ist verschieden! Sorry, das Lemma ist mißverständlich... Da ein Bild ist nicht gleich ein Lichtbild ist, habe ich mal eine Änderung vorgenommen (diff). Ein Bild ist vielmehr ein Überbegriff für eine Illustration. Illustrationen können sein: Grafiken, Karten, Lichtbilder, Videos uvm. Wer Wikipedia als eine umfassende Umsetzung des Wissens begreift, kommt um die Fragestellung nicht vorbei. WP sollte sich solcher einfachen, aber scheinbar doch nicht so einfacher Themen, nicht verschließen. Wenn's intern nicht klappt, klappt's extern auch nicht. Ich will damit sagen: Bitte stellt Euch dem Problem. Das Argument mit dem Befehl ist so zu sagen Schmu, weil es technischer Natur ist. Vielmehr geht es um die Charakteristik, was es für eine Bilddatei ist. Ich bin für eine Umleitung von Hilfe:Bild auf Hilfe:Illustration(en), das ist ein gangbarer Kompromiss finde ich. -- Bilderwelt 22:19, 19. Jul. 2007 (CEST)
- Ich sehe deinen Punkt, trotzdem bin ich gegen eine Verschiebung. Es geht hier mehr um den technischen Aspekt, eben den Befehl Bild:.... Zumal über diesen Befehl auch Video-, Audio-Dateien und PDFs eingebunden werden können. Die grundlegende Frage ist vielmehr eine Umbenennung des Befehls auf File:... bzw. Datei:.... Das ist aber eine Entscheidung auf oberster technischer Ebene, da tut sich seit Jahren nichts. --Raymond Disk. Bew.
- (BK): nun finde ich die diskussion nicht wirklich wertschaffend aber seis drum: aus Illustration: Eine Illustration ...bedeutet ...einem Text erläuternd beigegebene Bild in jedweder Form. - wenn ich es hochlade ist es noch gar nicht dem text beigegeben - und hier wird ja auch erklärt welche dateiformate ich verwenden soll usw. Und du Bilderwelt schreibst: Bild ist vielmehr ein Überbegriff für eine Illustration - na wunderbar?? also ist die illustration die vielleicht aus dem hochgeladenen Bild entsteht doch inbegriffen? Deine Ergänzung ist nach der von dir selbst genannten "definition" das bild ein oberbegriff eine redundanz an sich; etwa wie; es gibt Straßen, Autobahnen und Landstraßen auch die BKS Bild sieht wohl den Oberbegriff. ...Sicherlich Post 22:34, 19. Jul. 2007 (CEST)
- @Raymond: Wikipedia:Dateien gibts schon :o) ...Sicherlich Post 22:36, 19. Jul. 2007 (CEST)
- @Bilderwelt: Hier geht es um Technisches, du suchst vermutlich Wikipedia:Artikel illustrieren. Ich halte diese Trennung für gut und würde das nicht vermengen. --TM 10:10, 20. Jul. 2007 (CEST)
- OK, überzeugt. Bilderwelt 09:53, 7. Aug. 2007 (CEST)
Hilfe bei Gallerie
Ich habe im Artikel "Huckenohlstadion" eine Gallerie erstellt. Aber warum ist das letzte Bild in der nächsten Zeile, wie kann ich das ändern?? Wie kann ich die Bilder vergrößern? Danke! rusti 18:10, 27. Jul. 2007 (CEST)
- Galerien sehen immer so aus. Es ist nicht sinnvoll, das zu ändern. Der Leser ist daran gewohnt, dass alle Galerien in der Wikipedia gleich aussehen. --TM 18:16, 27. Jul. 2007 (CEST)
- Aber das letzte Bild passt doch noch in die erste Zeile, oder nicht?? rusti 18:20, 27. Jul. 2007 (CEST)
- Wie du mehr Bilder in eine Reihe bekommst steht in der Hilfe im Absatz Galerie schön beschrieben. Es ist aber nicht sinnvoll mehr als 4 Bilder pro Zeile zu nehmen, da Benutzer mit kleiner Fensterbreite dann seitlich scrollen müssen. Da wäre es eventuell noch besser du teilst es auf 3 + 2 auf, aber ich finde 4 + 1 ist doch auch ok. Größer sollen die Bilder eigentlich nicht sein, denn es ist ja nur eine Vorschau auf das Bild. Gruß, -- McFred 18:52, 27. Jul. 2007 (CEST)
- alles klar. vielen Dank. rusti 21:01, 27. Jul. 2007 (CEST)
Bildgröße in % von Bildschirmbreite?
Hallo! Gibt es eine Möglichkeit einem Bild zu befehlen, es soll sich der jeweiligen Bildschirmbreite anpassen, also zum Beispiel vom rechten Rand immer ein Viertel der Breite nach links rüber sich erstrecken? Danke, -- منشMan∞77龍 22:17, 6. Aug. 2007 (CEST)
- Nein, das ist nicht möglich, weil man dazu Styleangaben bei den Bildern machen müssen, was MediaWiki nicht erlaubt. --Revolus Δ 22:22, 6. Aug. 2007 (CEST)
Commons-Dateieinbindung
Commonsbilder, die hier als Bild erscheinen können ja bearbeitet werden. Sie sind einfach leer und haben das Bild und einen eingebundenen Text aus Commons. Wo steht, daß man die deutsche Seite (Bild:muster.jpg) nicht auch hier bearbeiten kann. Es ist zwar nicht so toll, weil man es auch auf den Commons reinschreiben könnte. Aber ich sehe ständig schnelllöschanträge für solche Eintragungen. Das ist ja nicht falsch. Meine Frage: Wo ist das geregelt und wo wird zentral diskutiert? --84.56.26.43 18:54, 12. Aug. 2007 (CEST)
- Muss man für alles eine Regelung haben? Hier sollte der gesunde Menschenverstand greifen. Alles was man braucht kann man auf Commons unterbringen. --129.13.186.4 19:00, 12. Aug. 2007 (CEST)
- Natürlich kann man das, bloß ist dann aber das Schnelllöschen kein gesunder Menschenverstand. Die meisten Admins übertragen die deutschen Infos nicht bei commons. 84.56.57.29 19:06, 12. Aug. 2007 (CEST)
- Also wenn es um drohenden Informationsverlust geht, dann braucht es auf jeden Fall eine Regelung! 84.56.57.29 19:20, 12. Aug. 2007 (CEST)
- Dort steht ja auch schon, dass nur redundante Beschreibungsseiten gelöscht werden. Ich persönlich empfinde es meist als überflüssig bei einem Commonsbild noch eine deutsche Beschreibungsseite zu behalten (Ausnahmen wie exzellente Bilder bestätigen die Regel). Es muss halt immer im Einzelfall entschieden werden. --jodo 19:25, 12. Aug. 2007 (CEST)
- Natürlich kann man das, bloß ist dann aber das Schnelllöschen kein gesunder Menschenverstand. Die meisten Admins übertragen die deutschen Infos nicht bei commons. 84.56.57.29 19:06, 12. Aug. 2007 (CEST)
Anpassung bei Parameter Upright?
Habe ich das was verschlafen? Mir scheint die Wertangabe bei Parameter upright neuerdings wirkungslos zu sein.--Cactus26 07:52, 26. Aug. 2007 (CEST)
- Ist ein Bug in der weitgehend neu geschriebenen Bildersoftware, u.a. in Vorbereitung auf die kommende Inline-Video-Darstellung. Ich schaue mir den Code an und versuche ihn zu fixen. --Raymond Disk. Bew.
- Es ist noch mehr defekt, u.a. auch die Option für abweichende Thumbnails. --Raymond Disk. Bew. 12:24, 26. Aug. 2007 (CEST)
- Danke für die Info, wünsche Dir, dass Du das in den Griff bekommst. Bin aber auch schon mal gespannt auf das neue Feature.--Cactus26 13:58, 26. Aug. 2007 (CEST)
- Danke für die Wünsche, sie haben geholfen, den upright- und manuellen-Thumbnail-Bug habe ich mit rev:25188 in den Griff bekommen. --Raymond Disk. Bew. 22:23, 27. Aug. 2007 (CEST)
- Gerne, nicht gerade beneidenswert, in diesem Code Fehler suchen zu müssen. Kann zwar kein PHP, kann den Code aber ganz gut lesen, da die Syntax ja C entspricht. Wenn ich es richtig verstehe, könnte der Kommentar (@param) auch noch angepasst werden, d.h. die Zeile "upright_factor" entfernt werden. Jedenfalls nochmal danke für Deine schnelle Abhilfe!--Cactus26 15:37, 28. Aug. 2007 (CEST)
- Danke für die Wünsche, sie haben geholfen, den upright- und manuellen-Thumbnail-Bug habe ich mit rev:25188 in den Griff bekommen. --Raymond Disk. Bew. 22:23, 27. Aug. 2007 (CEST)
Kleine Bilder nicht hässlich vergrößern
Ich war schon vor einigen Monaten erfolglos auf der Suche nach einer Möglichkeit, Bilder so in Infoboxen einzubinden, dass sie nicht hässlich aufgeblasen werden. Die MediaWiki-Software verhält sich in diesem Punkt leider sehr inkonsistent: Wenn man ein z. B. nur 36 Pixel breites Bild mit thumb|120px einbindet, wird es nicht künstlich aufgeblasen. Das ist das von mir gewünschte Verhalten. Dummerweise erzwingt der Parameter thumb gleichzeitig den Bildrahmen, der innerhalb von Infoboxen stören würde. Ohne den Parameter thumb wird das Bild aber plötzlich über seine ursprüngliche Größe hinweg gedehnt.
[[Bild:…|thumb|120px]] | [[Bild:…|frameless|120px]] | [[Bild:…|120px]] | <gallery> |
Korrekt: Das Bild wird nicht vergrößert, denn es ist im Original nur 36px groß. | Falsch: Das Bild muss genau wie im thumb-Beispiel links in seiner Originalgröße angezeigt werden. | Fragwürdig: Ich denke, auch in diesen Fällen darf das Bild nicht vergrößert werden. |
Abhängig vom verwendeten Webbrowser sieht das hässlich bis grauenhaft aus. Die einzige Notlösung, die mir bisher dafür eingefallen ist, ist ein zusätzlicher Vorlagenparameter. Auf diesen würde ich jedoch gern verzichten, denn die dahinter liegende Logik „wenn Thumbgröße größer als Originalgröße dann verwende Originalgröße“ soll doch bitte von der MediaWiki-Software übernommen werden und nicht von den Artikelautoren. Was ich gern möchte ist das Verhalten des Parameters thumb, Bitmapformate (also alle außer SVG) nicht über ihre Originalgröße hin aufzublähen, und zwar egal ob mit oder ohne Thumbnail-Rahmen.
Dazu schlug ich damals einen neuen Parameter noborder vor. Dieser hätte gleichzeitig den Vorteil, dass es möglich wäre, auch rahmenlose Bilder so einzubinden, dass sich ihre Größe mit den Einstellungen des Benutzers ändert. Das ist momentan gar nicht möglich (die Funktionen „zeige Thumbnail-Rahmen“ und „zeige Bild in benutzerdefinierter Größe“ sind beide vom Parameter thumb abhängig und lassen sich nicht trennen).
Die einfachere aber weniger flexible Lösung wäre, bei allen Bildern die Sperre einzubauen, die Vergrößerungen über die Originalgröße hinaus blockiert (nicht nur bei Bildern mit dem Parameter thumb). --TM 18:04, 16. Sep. 2007 (CEST)
- Der von dir gewünschte Parameter noborder wurde von mir vor ca. 2 Monaten entwickelt, allerdings heißt er „frameless“:
- [[Bild:Groß St. Martin bei Nacht.jpg|frameless|right|Groß St. Martin bei Nacht]]
- Das Aufblasen von Bildern gefällt mir auch nicht, ich muss mal schaun, ob das ein Bug oder ein Feature ist. — Raymond Disk. Bew. 09:19, 17. Sep. 2007 (CEST)
- Interessant. Der Parameter frameless bewirkt also, dass das Bild in der benutzerdefinierten Thumbnail-Größe dargestellt wird, jedoch ohne Rahmen. Das ist gut zu wissen (ich werde das bei Gelegenheit auf der Hilfeseite erwähnen). Leider wird das Bild dabei ebenfalls hässlich vergrößert (siehe oben). Ich denke, an dieser Stelle muss das Selbe wie beim thumb-Bild passieren. Kannst du das bitte noch umsetzen? --TM 22:05, 17. Sep. 2007 (CEST)
- Hmm ja, wobei die Kombination frameless + Pixelangabe nicht sinnvoll ist. Das frameless wird dann einfach ignoriert und das Basisproblem der unerwünschten Vergrößerung taucht auf. Ich schaue mir den Coder aber gerne nochmal an, warum überhaupt vergrößert wird bzw. warum es bei thumb nicht passiert. — Raymond Disk. Bew. 23:12, 17. Sep. 2007 (CEST)
- Es wäre nur unter einer Bedingung sinnvoll:
- frameless|120px funktioniert genau wie thumb|120px, sehr kleine Bilder werden also nicht vergrößert.
- Ohne thumb und ohne frameless werden alle Bilder auf 120px skaliert, auch sehr kleine.
- Ich bezweifle jedoch, dass das so beabsichtigt ist. Ich würde wie oben dargestellt Bilder nie über ihre Originalgröße vergrößern. Das selbe Problem gibt es übrigens auch in der <gallery>, siehe oben.
- Es wäre nur unter einer Bedingung sinnvoll:
- Hmm ja, wobei die Kombination frameless + Pixelangabe nicht sinnvoll ist. Das frameless wird dann einfach ignoriert und das Basisproblem der unerwünschten Vergrößerung taucht auf. Ich schaue mir den Coder aber gerne nochmal an, warum überhaupt vergrößert wird bzw. warum es bei thumb nicht passiert. — Raymond Disk. Bew. 23:12, 17. Sep. 2007 (CEST)
- Achtung: SVG ist ein Sonderfall. SVGs dürfen immer beliebig skaliert werden. --TM 10:00, 18. Sep. 2007 (CEST)
Tja, das war ein Satz mit X. Ich hatte den vermeintlichen Fehler im MediaWiki-Corecode geändert, hat jedoch nur eine knappe Stunde gehalten, dann hat Brion ihn wieder rausgeworfen:
[15:25] <CIA-6> raymond * r25916 /trunk/phase3/ (RELEASE-NOTES includes/Linker.php): Moving code from Linker::makeThumbLink2 to Linker::makeImageLink2 This will prevent bigger images than the source (for bitmap-style images) [[Image:smallIconWith25px.png|200px]] does not blow the bitmap to 200px width Now the same behavior as [[Image:smallIconWith25px.png|thumb|200px]] which prevents blow up already. ... [16:30] <CIA-6> brion * r25917 /trunk/phase3/ (RELEASE-NOTES includes/Linker.php): Revert r25916 -- breaks ability to blow up small images, without explanation. WTF? [16:34] <Raymond_> brion-office: the ability to blow up small images looks to me like a bug not a feature because it is prevented for |thumb| images already <brion-office> Raymond_: well, you're wrong it's a deliberate feature
— Raymond Disk. Bew. 16:52, 18. Sep. 2007 (CEST)
- Dann behebt doch wenigstens den Teil dieses Problems, der die Diskrepanz zwischen thumb und frameless betrifft. In Kombination mit frameless sollte das Aufblähen auf jeden Fall verhindert werden, wie in den beiden ersten Beispielen oben gezeigt. Das wäre die flexibelste Lösung: Das Standardverhalten bleibt unangetastet, aber wenn man es benötigt, kann man das Aufblähen mit frameless verhindern. --TM 17:02, 18. Sep. 2007 (CEST)
Warum kommt es zu "Aus technischen Gründen kommt es momentan zu Anzeigefehlern bei einigen Bildern"?
Im Moment sehe ich dauernt diese Überschrift. Ich kapier' das schon, aber aus Neugierde würde ich gerne wissen, wsdahintersteckt. Danke!--Supereditor 17:29, 19. Sep. 2007 (CEST)
- Die Hamster streiken im Moment. Entweder stimmt etwas mit dem Squid-Netzwerk oder dem lighttp-Server nicht. Das ist der letzte Stand, den ich weiß. --Revolus Δ 17:34, 19. Sep. 2007 (CEST)
Röntgenbilder vom Arzt
Ich habe Röntgenbilder von meinem Arzt auf einer CD gekriegt. Ein Bild wäre sehr gut geeignet einen Artikel deutlich zu illustrieren. Ich stelle mir aber die Frage, wem das Bild eigtl. gehört? Mir, meinem Arzt? Wie sieht das lizenztechnisch aus? --Freiermensch 21:04, 9. Okt. 2007 (CEST)
- Diese Frage gehört eigentlich nach WP:UF. Kurz: Der Urheber des Bildes ist dein Arzt. Er müsste in eine Freigabe erteilen. --TM 23:56, 9. Okt. 2007 (CEST)
Thumb ohne Rahmen?
Ist wahrscheinlich schon mal gestellt: Kann beim Bildbefehl "thumb" der Rahmen unterdrückt werden, so dass sich das Bild ohne festen Parameter an die jeweiligen Einstellungen anpasst, aber ohne Rahmen und Bildunterschrift erscheint? --Thomas W. 23:15, 10. Okt. 2007 (CEST)
- Ja, das geht mit [[Bild:|frameless]] oder [[Bild:|frameless|border]]. --Revolus Echo der Stille 23:25, 10. Okt. 2007 (CEST)
- Supi, Danke und Gruß! --Thomas W. 23:33, 10. Okt. 2007 (CEST)
Thumbnail in der Mediawiki aktivieren?
Hallo Expreten!
Ich habe ein kleines Projekt zu SL gestartet, habe die MediaWiki aufgesetzt und auch die Cite erweiterung installiert. Bei ImageMagick-6.3.5-6.zip happert es ganz gewaltig - kann mir jemand ein paar Links geben wo die Installation Schritt für Schritt erklärt wird? Es will einfach nicht funktionieren... zumal es keine install anleitung gibt... Bin für jeden Tipp dankbar! Entweder hier antworten oder direkt eine mail an kontakt@secondforum.de
Danke im Voraus!(nicht signierter Beitrag von 85.180.27.158 (Diskussion) 16:01, 18. Aug. 2007 (CEST))
- Vielleicht helfen die dir resize-Einstellungen unter: http://www.mediawiki.org/wiki/Manual:LocalSettings.php#Image_uploads weiter. Dort ist vielleicht eine besserer Platz für deine Frage. --Kolossos 17:14, 18. Aug. 2007 (CEST)
danke kolossos - aber den upload habe ich soweit im griff... es geht nur um die thumbnails....(nicht signierter Beitrag von 85.180.27.158 (Diskussion) 16:27, 18. Aug. 2007 (CEST))
Bilder aus anderen Wikis
Servus!
Wenn ich ein Bild aus einem anderen Wiki (konkret sl:Slika:Zrcalna_slika.jpg) einbinden will, geht das direkt oder muß ich es erst in die Commons oder nach de: verschieben?
Danke voraus.
Gruß, Ciciban 12:22, 22. Aug. 2007 (CEST)
- Die Lizenz auf sl: sieht gut aus (GFDL), daher kannst du es sofort nach Commons verschieben, siehe auch Wikipedia:Wikimedia Commons#Umzug von Bildern auf die Commons. --Raymond Disk. Bew. 12:31, 22. Aug. 2007 (CEST)
- Was meine Frage leider nicht beantwortet: Gibt es einen direkten Aufruf auch?
Gruß, Ciciban 13:32, 22. Aug. 2007 (CEST)- Bilder mit ausreichender Lizenz sollten immer in die Commons geladen werden, damit alle Wikipedias und sonstigen Wiki-Projekte zentral darauf zugreifen können. Ein direkter Zugriff von de auf sl ist dann unnötig.-- MSchnitzler2000 14:16, 22. Aug. 2007 (CEST)
- Sorry, die Frage nur halb gelesen. Ein direkter Zugriff auf Bilder in anderen Projekten ist grundsätzlich nicht möglich. Nur Bilder von Commons können bei uns eingebunden werden. --Raymond Disk. Bew. 14:30, 22. Aug. 2007 (CEST)
- Danke.
Gruß, Ciciban 08:22, 26. Aug. 2007 (CEST)
- Danke.
- Was meine Frage leider nicht beantwortet: Gibt es einen direkten Aufruf auch?
Ich habe schon mehrfach versucht, Bilder aus der holländischen Wiki in Artikel einzubinden, im aktuellen Fall von Rotterdamse Schie. Die Bilder sind in Commons gelistet, trotzdem kann ich sie nicht herunterladen. Was mache ich falsch?--Frila 10:18, 12. Okt. 2007 (CEST)
- Hallo, ich kann dort kein Bild entdecken die in Commons stehen. Die zwei dort sind nicht in Commons. Gruß -- Rainer Lippert 10:23, 12. Okt. 2007 (CEST)
- Hallo Rainer, ich habe mich da vertan, die Bilder sind bei Wiki NL unter Categorie: Wikipedia:Afbeeldingen in het publiek domein (auteursrecht verlopen) gelistet. Wenn ich mich bei Wiki NL anmelde, kann ich die Bilder runterladen, wie bekomme ich sie bei Wki DE eingebunden? Gruß--Frila 11:20, 12. Okt. 2007 (CEST)
- Prüfen, ob die NL-Bilder auf commons willkommen sind. Dann nach commons verschieben. -- Smial 12:17, 12. Okt. 2007 (CEST)
- Hallo Frila, Smial sagt es so richtig. Wenn die Lizenz in Ordnung ist, nach Commons hochladen, dann in de einbinden. Eine Anleitung dazu findest du hier. Gruß -- Rainer Lippert 19:25, 12. Okt. 2007 (CEST)
WP:en
Möchte aus WP:en DiaphragmCompressor.jpg im Artikel Druckluftanlage haben. Was ist ein sinnvolles Verfahren? Erst von WP:en nach Commons?--Kölscher Pitter 13:41, 5. Nov. 2007 (CET)
- Ja, bitte nach commons, wenn es die Lizenz zuläßt. -- Smial 14:38, 5. Nov. 2007 (CET)
Abweichender Link?
Ich habe folgendes Problem: Ich möchte eine PDF-Datei einbinden. Dazu habe ich eine SVG-Datei, die man als Thumbnail nehmen könnte. Ich hätte dan gerne, daß wenn man auf die Abbildung (die SVG) klickt, man auf die Bildbeschreibungsseite mit dem PDF gelangt. (Andersherum ist dies möglich, nämlich indem man einen abweichenden Thumbnail angibt.) -- Tischbeinahe φιλο 22:28, 6. Nov. 2007 (CET)
PS: Die zwei Bilder: [2] und [3]
- Hilfe:Bilder#Imagemaps ist dein Freund:
- Super! Vielen Dank! -- Tischbeinahe φιλο 22:44, 6. Nov. 2007 (CET)
Abstand unterhalb des Galerietextes
Unterhalb des Beschriftungstextes bei einer Galerie ist ein recht großer Abstand:
<gallery> Bild:Rotkehlchen_gr.jpg|Rotkehlchen Bild:Gaense2004.jpg|Gänse Bild:Waran.jpg|Komodowaran Bild:Cat outside.jpg|Hauskatze </gallery>
-
Rotkehlchen
-
Gänse
-
Komodowaran
-
Hauskatze
Im erzeugten XHTML ist zu erkennen, dass dieser Abstand durch ein leeren Absatz entsteht: <p><br /></p>
. Wenn ich mich recht erinnere war dieser leere Absatz war nicht schon immer da, sondern muss irgendwo in MediaWiki eingebaut worden sein. Ich halte das für einen schlechten Workaround und eigentlich ein Fehler der wieder rückgängig gemacht werden sollte. Einen größeren Innenabstand unterhalb des Textes wird sinnvoller folgendermaßen erzeugt:
div.gallerytext { padding-bottom: 1.5em }
Sollte das an die MediaWiki-Entwicker weitergemeldet werden? --Fomafix 14:52, 7. Nov. 2007 (CET)
- Das ist (leider) ein Workaround der MediaWiki-Entwickler. Kommentar im Sourcecode:
# ATTENTION: The newline after <div class="gallerytext"> is needed to accommodate htmltidy which # in version 4.8.6 generated crackpot html in its absence, see: # http://bugzilla.wikimedia.org/show_bug.cgi?id=1765 -Ævar
- — Raymond Disk. Bew. 15:10, 7. Nov. 2007 (CET)
- Das kann’s eigentlich nicht sein, denn wenn ich mir den Code anschaue:
$s .= $sk->makeKnownLinkObj( $nt, $thumb->toHtml() ) . '</div><div class="gallerytext">' . "\n" .
$textlink . $text . $nb .
'</div>';
- dann wird das
"\n"
vor dem Text eingefügt. Der leere Absatz entsteht aber nach dem Text. Der leere Absatz oder der doppelte Zeilenumbruch aus dem der leere Absatz entsteht muss also bereits in einem der Variablen$textlink
,$text
oder$nb
stecken. --Fomafix 16:21, 7. Nov. 2007 (CET)- Es es wurde vor neun Monaten wirklich daran gedreht. Der aktuelle Code enthält
- dann wird das
$s .=
"\n\t\t" . '<td><div class="gallerybox" style="width: '.($this->mWidths+35).'px;">'
. $thumbhtml
. "\n\t\t\t" . '<div class="gallerytext">' . "\n"
. $textlink . $text . $nb
. "\n\t\t\t</div>"
. "\n\t\t</div></td>";
- und erzeugt ein zusätzliches
"\n"
vor dem schließenden</div>
, obwohl$text
bzw.$nb
bereits ein Zeilenumbruch enthält, wie weiter oben im Quellcode zu sehen ist. --Fomafix 17:05, 7. Nov. 2007 (CET)
- und erzeugt ein zusätzliches
- Jein. Du hast jetzt zwar den aktuellen Code gefunden, aber daran liegt es nicht. In meiner lokalen MediaWiki-Installation wird kein zusätzlicher Zeilenumbruch eingefügt. Der muss daher von Tidy kommen, den habe ich nicht installiert. Wenn ich mich nicht täusche, formatiert
"\n"
usw. auch nur den HTML-Quelltext, wirkt sich aber nicht auf die gerenderte Ausgabe aus. Es lohnt einer genaueren Untersuchung :-) — Raymond Disk. Bew. 17:30, 7. Nov. 2007 (CET)- Im normalem Wikitext wird aus einer Leerzeile (doppelter Zeilenumbruch
\n\n
) ein Wechsel auf ein neuen Absatz. Bei einer doppelten Leerzeile (dreifacher Zeilenumbruch\n\n\n
) wird zwischen den beiden Absätzen ein leerer Absatz (<p><br /></p>
) eingefügt. Beispiel:
- Im normalem Wikitext wird aus einer Leerzeile (doppelter Zeilenumbruch
- Jein. Du hast jetzt zwar den aktuellen Code gefunden, aber daran liegt es nicht. In meiner lokalen MediaWiki-Installation wird kein zusätzlicher Zeilenumbruch eingefügt. Der muss daher von Tidy kommen, den habe ich nicht installiert. Wenn ich mich nicht täusche, formatiert
Absatz 1 \n\n
Absatz 2 \n\n\n
Absatz 3
- Wenn diese Transformation auf der Ausgabe von ImageGallery.php angewendet wird, dann würden genau die
\n
für den leeren Absatz verantwortlich sein. - Der eigentlichen Beschreibungstext wird auch unnötigerweise in ein
<p>
-Element verpackt:<div class="gallerytext"><p>Rotkehlchen</p><p><br/></p></div>
. Folgender Wikicode führt ebenfalls zu diesem Ergebnis:
- Wenn diese Transformation auf der Ausgabe von ImageGallery.php angewendet wird, dann würden genau die
<div class="gallerytext"> Rotkehlchen </div>
Rotkehlchen
- Korrekt wäre folgendes in einer Zeile:
<div class="gallerytext">Rotkehlchen</div>
- Wozu überhaupt die Quellcodeformatierung mit \t und \n, wenn danach der Code sowieso nochmal überarbeitet wird? Von den Tabulatoren und den Zeilenumbrüchen kommt zumindest nichts an. Kann das jemand überprüfen? --Fomafix 10:15, 8. Nov. 2007 (CET)
Falsche Einrückung bei Aufzählungen neben Thumbs mit Attribut "left"
Ist das schon immer so, dass die Einrückung nicht korrekt ist bei Verwendung von "*" und "#" für Aufzählungen? (siehe Sturpen), wenn ein Bild links dargestellt wird? (Browser=Firefox) --Cactus26 15:53, 23. Okt. 2007 (CEST)
- Kurz gesagt: ja. Bei dem von dir genannten Artikel habe ich einen kleinen Hack eingefügt, so dass es jetzt korrekt aussehen sollte. Gruß, --Revolus Echo der Stille 16:08, 23. Okt. 2007 (CEST)
Meiner Meinung nach ist das ein Fehler in der CSS-Definition von MediaWiki in main.css. Hier ein Beispiel:
- erster
Punkt - zweiter
Punkt - dritter
Punkt - vierter
Punkt - fünfer
Punkt - letzter
Punkt
Das selbe in HTML-Syntax
- erster
Punkt - zweiter
Punkt - dritter
Punkt - vierter
Punkt - fünfer
Punkt - letzter
Punkt
Bisher steht
ul {
line-height: 1.5em;
list-style-type: square;
margin: .3em 0 0 1.5em;
padding: 0;
list-style-image: url(bullet.gif);
}
ol {
line-height: 1.5em;
margin: .3em 0 0 3.2em;
padding: 0;
list-style-image: none;
}
li {
margin-bottom: .1em;
}
Mit folgender Definition müsste es gehen:
ul {
line-height: 1.5em;
list-style-type: square;
margin: .3em 0 0 0;
padding: 0;
list-style-image: url(bullet.gif);
}
ol {
line-height: 1.5em;
margin: .3em 0 0 0;
padding: 0;
list-style-image: none;
}
li {
margin-bottom: .1em;
}
ul > li {
margin-left: 1.5em;
}
ol > li {
margin-left: 3.2em;
}
- erster
Punkt - zweiter
Punkt - dritter
Punkt - vierter
Punkt - fünfer
Punkt - letzter
Punkt
Ich werde es gleich in meine monobook.css aufnehmen und testen. --Fomafix 19:34, 23. Okt. 2007 (CEST)
- Danke für die Mühe! Wäre schön, wenn wir das lösen könnten. Kann Deiner Darstellung nur bedingt folgen, da ich von CSS und auch HTML zu wenig verstehe. Nur interessehalber: Du verlagerst die Indend-Definition von der Liste (ol,ul) zum Listenelement, verstehe ich das richtig?--Cactus26 08:05, 24. Okt. 2007 (CEST)
- Genau, statt einen linken Margin für die gesamte Liste setze ich jedem Listenelement einen linken Margin. Ich habe die obigen CSS-Definition in meine monobook.css aufgenommen. Beim Firefox werden damit Aufzählungen bei Fließobjekten korrekt eingerückt. Ich musste allerdings ein paar weitere Definitionen ergänzen, bzw. überschreiben, damit sich die Darstellung bei der linken Spalte und beim Inhaltsverzeichnis nicht ändert. Dazu ist wahrscheinlich noch etwas Feinarbeit notwendig.
- Bei Opera und Internet Explorer korrigiert diese Änderung den Fehler leider nicht. Die Darstellung bleibt gleich, sodass diese Änderung auch keine Verschlechterung bewirkt. Da der Internet Explorer 6 keine Child selectors versteht, musste ich es zusätzlich als Descendant selector definieren. Beim Internet Explorer ergibt sich daher bei seltenen Fall von
ol
→li
→ul
→li
eine zu weite Einrückung. - Diese Änderung ist prinzipiell die richtige Lösung und behebt beim Firefox das Problem. Da sie aber nur beim Firefox funktioniert, sorgt sie für eine uneinheitliche Darstellung zwischen den Browsern. --Fomafix 22:08, 24. Okt. 2007 (CEST)
- Hey, danke für Deinen Schnellkurs in CSS. Verstehe hier zwar nur Bruchstücke (warum das toc beeinflusst ist, habe ich z.B. noch nicht kapiert), auch rate ich (noch) ein wenig, was die einzelnen Parameter so eigentlich bedeuten. Habe dennoch selbst mal ein wenig rumgebastelt (siehe meine monobook.css). Dabei eine naive Idee. Die zu große Einrückung bei ol /ul Schachtelung (die z.B. dort existiert) könnte man doch auch bei Verwendung von Descandant Selectors wieder durch ol li ul li { margin-left: 1.5em; } kompensieren. Die umgekehrte Schachtelung bräuchte man vielleicht auch noch. Besteht eigentlich eine Chance, dass das ganze irgendwann mal nach main.css wandert?--Cactus26
- Ohne Child Selector bekommt man das nicht vollständig hin. Bei der Kombination
- Hey, danke für Deinen Schnellkurs in CSS. Verstehe hier zwar nur Bruchstücke (warum das toc beeinflusst ist, habe ich z.B. noch nicht kapiert), auch rate ich (noch) ein wenig, was die einzelnen Parameter so eigentlich bedeuten. Habe dennoch selbst mal ein wenig rumgebastelt (siehe meine monobook.css). Dabei eine naive Idee. Die zu große Einrückung bei ol /ul Schachtelung (die z.B. dort existiert) könnte man doch auch bei Verwendung von Descandant Selectors wieder durch ol li ul li { margin-left: 1.5em; } kompensieren. Die umgekehrte Schachtelung bräuchte man vielleicht auch noch. Besteht eigentlich eine Chance, dass das ganze irgendwann mal nach main.css wandert?--Cactus26
ul li { margin-left: 1.5em }
ol li { margin-left: 3.2em }
ol ul li { margin-left: 1.5em }
ul ol li { margin-left: 3.2em }
- würde ein
ul
→li
→ol
→li
→ul
→li
immer noch zu weit eingerückt werden. Allerdings denke ich, dass ein verschachteltesol
auch ohne große Einrückung gut oder sogar besser aussieht. Dann würde folgende einfache CSS-Definition (in dieser Reihenfolge) ausreichen:
- würde ein
ol li { margin-left: 3.2em }
li ol li,
ul li { margin-left: 1.5em }
- Statt der bisherigen Darstellung
- erster
Punkt - zweiter
Punkt- erster
Punkt - zweiter
Punkt
- erster
- dritter
Punkt
- würde folgende Darstellung entstehen:
- erster
Punkt - zweiter
Punkt- erster
Punkt - zweiter
Punkt
- erster
- dritter
Punkt
- Diese CSS-Definiton sind generell sehr tiefgreifend und beeinflussen Aufzählungen an allen Stellen, nicht nur bei den Artikeln. Es muss alles getestet und ggf. Folgeanpassungen durchgeführt werden. --Fomafix 09:15, 25. Okt. 2007 (CEST)
Ich Finde das mit dem geringeren Indend bei ul -> ol auch schöner (würde sogar grundsätzlich schöner finden, wenn bullets und nummern mit gleicher Einrückung verwendet würden). Was mir noch aufgefallen ist: Die Einrückung mittels WP-Tag ":" funktioniert wohl in der "Bild-links-Konstellation" auch nicht korrekt.--Cactus26 11:04, 25. Okt. 2007 (CEST)
- Nummerierte Aufzählungen haben eine breitere Einrückung, weil die Zahlen mehr Platz benötigen können.
Richtig, bei Definitionslisten funktioniert die Einrückung bei Fließobjekten auch nicht. Hier ein Beispiel in Wikisyntax:
- Definitionsterm 1
- erster
Punkt - Definitionsterm 2
- zweiter
Punkt - Definitionsterm 3
- dritter
Punkt - Definitionsterm 4
- vierter
Punkt
Gleiches Beispiel in HTML-Syntax:
- Definitionsterm 1
- erster
Punkt - Definitionsterm 2
- zweiter
Punkt - Definitionsterm 3
- dritter
Punkt - Definitionsterm 4
- vierter
Punkt
main.css enthält hier aber bereits die richtige Definition:
dt {
font-weight: bold;
margin-bottom: .1em;
}
dl {
margin-top: .2em;
margin-bottom: .5em;
}
dd {
line-height: 1.5em;
margin-left: 2em;
margin-bottom: .1em;
}
Leider hat der Firefox wie die anderen Browser hier keine spezielle Unterstützung. Folgender Hack scheint aber zu funktionieren:
dd { display: table }
- Definitionsterm 1
- erster
Punkt - Definitionsterm 2
- zweiter
Punkt - Definitionsterm 3
- dritter
Punkt - Definitionsterm 4
- vierter
Punkt
Ich werde auch das bei noch weiter testen. --Fomafix 12:36, 25. Okt. 2007 (CEST)
Hat zwar nix mit dem bisherigen Thema zu tun: Dann könnte man auch die Art der Nummerierung für untergeordnete Ebenen ändern: ol ol { list-style-type:lower-latin; } (siehe meine monobook.css und zum Test Zimmern (Adelsgeschlecht)). Auch für weitere untergeordnete Ebenen, auch abweichende Bullets für untergeordnete ul. Hat mich schon immer gewundert, warum Wikipedia das nicht kann. Es wäre ja so einfach.... --Cactus26 17:42, 25. Okt. 2007 (CEST)
- Eine Änderung der Symbole oder Aufzählungzeichen ist sehr weitreichend. Was für Zimmern (Adelsgeschlecht) ganz gut aussieht, mag bei anderen Artikeln stören. Klar, jeder angemeldete Benutzer kann sich seine Darstellung per CSS selbst anpassen. Die globalen Einstellungen für Wikipedia finde ich aber im allgemeinen ganz gut.
Meine oben beschriebene Methode mit dd { display: table }
behebt zwar das Problem beim Firefox, hat aber einige andere unerwünschte Nebeneffekte. Ich habe noch eine andere Möglichkeit gefunden: dd { overflow: hidden }
.
- Definitionsterm 1
- Definitionsterm 2
- Definitionsterm 3
- Definitionsterm 4
Ich werde es noch genauer untersuchen. --Fomafix 17:10, 28. Okt. 2007 (CET)
Habe den relevanten Teil Deiner monobook.css in meine übernommen, melde Dir, wenn mir was unerwünschtes auffallen sollte.--Cactus26 07:07, 29. Okt. 2007 (CET)
- Dein neuer dd-Workaround scheint bei den in Diskussionen typischen mehrfachen Schachtelungen zus. Leerzeilen zu produzieren.--Cactus26 07:18, 29. Okt. 2007 (CET)
- Das liegt daran, dass die Ränder bei
overflow:hidden
nicht kollabieren: Vertical margins of elements with 'overflow' other than 'visible' do not collapse with their in-flow children. [4]. Eine saubere Lösung dieses Problems fällt mir im Moment nicht ein, außer die Ränder auf 0 zu setzen:dl, dt { margin-top:0; margin-bottom:0; }
--Fomafix 01:07, 31. Okt. 2007 (CET)overflow:hidden
hat noch weitere Nachteile: Der linke Rahmen um eine Tabelle ist überfließend und wird daher versteckt:
- Das liegt daran, dass die Ränder bei
- Damit hat
dd { overflow:hidden }
zu viele Nebenwirkungen und ist nicht geeignet. --Fomafix 10:55, 31. Okt. 2007 (CET)- Auch bei den anderen Einstellungen für ol/ul sind mir Nebeneffekte aufgefallen: Bei der Liste neuer Seiten sind die Nummern zu weit links, auch die Bullets der Beobachtungsliste sind weiter links.--Cactus26 11:26, 31. Okt. 2007 (CET)
- Richtig. Mit
.special li { margin-left: 3.2em; }
kann man das kompensieren. Die main.css muss von Grund auf neu aufgebaut werden, damit alle Verwendungen angepasst werden.- Habe Deine aktualisierte monobook.css wieder übernommen und werden weiter mittestetn.--Cactus26 18:04, 1. Nov. 2007 (CET)
- Richtig. Mit
- Auch bei den anderen Einstellungen für ol/ul sind mir Nebeneffekte aufgefallen: Bei der Liste neuer Seiten sind die Nummern zu weit links, auch die Bullets der Beobachtungsliste sind weiter links.--Cactus26 11:26, 31. Okt. 2007 (CET)
- Damit hat
Das geringere Einrücken von nummerierten Unteraufzählungen wirkt sich im folgenden Fall negativ aus. Die Nummerierung läuft in den Rahmen über.
- erster
Punkt - zweiter
PunktBox in der Box
- erster
Punkt - zweiter
Punkt
- erster
- dritter
Punkt
Mit reiner Wikisyntax (*
und #
) ist dieser Fall aber nicht zu konstruieren, so dass dies in der Praxis kein Darstellungsproblem verursachen wird. --Fomafix 09:06, 13. Nov. 2007 (CET)
Passage entfernt
Eine andere Anwendung: Bei einigen Bildern verschwinden in der Thumbnail-Ansicht wichtige Details. Beim Vergrößern erscheint dann das komplette Bild. {| border="0" style="border-collapse:collapse; background-color:transparent;" cellpadding="3"<br> |[[Bild:Ac-logo1.gif|thumb|none|160px|Ohne Thumbnail: unansehnlich]]<br> |[[Bild:Ac-logo1.gif|thumbnail=Ac-logo4.gif|none|Mit Thumbnail: Details gut erkennbar]] |}
Das funktioniert nicht, ebenso funktionieren die abweichenden Thumbnails nicht, daher habe ich den Artikeltext an der entsprechenden Stelle (Bitte auf das Bild klicken
) leicht modifiziert (→ Bitte auf das Vergrößern-Symbol neben diesem Text klicken
). MfG, --Paunaro 00:49, 21. Nov. 2007 (CET)
Außerdem werden in der englischen Wikipedia abweichende Thumbnails nicht mehr angeführt, wahrscheinlich ist diese Syntax veraltet. Siehe bitte Help:Images and other uploaded files und Wikipedia:Extended image syntax. MfG, --Paunaro 01:10, 21. Nov. 2007 (CET)
Nutzung des Gallery-Tags mit mehr als 4 Bildern pro Reihe
Hallo zusammen,
ich nutze Wikimedia 1.9.3., doch leider scheint bei mir der Parameter "Perrow" nicht richtig zu funktionieren. Egal was ich mache, es werden immer nur 4 Bilder pro Reihe angezeigt. Ich möchte jedoch eine Gallery mit dem <Gallery>-Tag erstellen, bei dem mehr als 4 Bilder pro Reihe gezeigt werden. Dazu habe ich folgendes genutzt (die Parameter heights und widths habe ich weggelassen):
<gallery caption="meine Gallerie" perrow="6"> bild:bild1.jpg|Bildunterschrift1 bild:bild2.jpg|Bildunterschrift2 bild:bild3.jpg|Bildunterschrift3 bild:bild4.jpg|Bildunterschrift4 bild:bild5.jpg|Bildunterschrift5 bild:bild6.jpg|Bildunterschrift6 bild:bild7.jpg|Bildunterschrift7 bild:bild8.jpg|Bildunterschrift8 bild:bild9.jpg|Bildunterschrift9 bild:bild10.jpg|Bildunterschrift10 bild:bild11.jpg|Bildunterschrift11 bild:bild12.jpg|Bildunterschrift12 </gallery>
Kann mir bitte jemand den Tip geben, wie ich das hinbekomme? Laut Wiki-Hilfe soll dies ab Version 1.4 funktionieren.
Danke und viele Grüße
TurboKanne, 12.Dezember 2007 16:03 (nicht signierter Beitrag von 217.5.159.40 (Diskussion) )
- Hallo TurboKanne,
- das perrow-Tag wurde erst am 6. Februar 2007 eingeführt. MediaWiki 1.9.0 wurde jedoch bereits am 10. Januar 2007 herausgegeben. Damit ist perrow erst ab Version 1.10.0 verfügbar. Die Versionen 1.9.x enthalten lediglich Security-Fixes, jedoch keine neuen Features. — Raymond Disk. Bew. 16:52, 12. Dez. 2007 (CET)
- Hallo Raymond,
- Danke für die promte Antwort. Darauf wäre ich nicht gekommen, habe es an einer 1.10er Version getestet und es funktioniert. D.h. ich werde mit meiner Live-Version wohl ein Update durchführen müssen. Super Tip - Danke, das hat mir sehr geholfen.
- viele Grüße
- TurboKanne, 12.Dezember 2007 17:09
Imagemap, scrollbares Panorama und IE
Ich habe hier versucht, ein Panoramabild als Imagemap horizontal scrollbar darzustellen. Mit dem Firefox klappt das auch ganz gut, der IE stellt das Bild aber auf voller Breite dar, so dass trotz richtig eingeblendeter Bildlaufleiste das Bild rechts über diese hinausgeht und die Scrollleisten des Browserfensters genutzt werden müssen. Hat jemand eine Lösung dafür? --Niteshift 22:51, 2. Nov. 2007 (CET)
- Mit den Containern aus Vorlage:Großes Bild funktioniert das auch für Imagemaps: --Fomafix 08:59, 21. Nov. 2007 (CET)
Details zu den einzelnen Attributen sind unter Vorlage Diskussion:Großes Bild erörtert. Sollte daraus eine Vorlage gebastelt werden? --Fomafix 08:59, 21. Nov. 2007 (CET)
Geht leider doch nicht beim Internet Explorer. DasIm folgenden habe das ich dasposition:relative
aus dem Imagemap unterhalb desoverflow:auto
aus der Vorlage:Großes Bild scheint den Internet Explorer durcheinander zu bringen.position:relative
mitoverflow:auto
im gleichendiv
-Container zusammengesetzt. Das Imagemap ist dabei deaktiviert, aber wenn es hier funktioniert, dann würde es auch durch eine MediaWiki-Erweiterung bei Imagemaps machbar sein.
Dazu bräuchte imagemap
einen Parameter, über den die CSS-Parameter overflow-y:hidden; overflow-x:scroll; overflow:auto; width:100%; width:inherit;
aktiviert werden. --Fomafix 09:40, 21. Nov. 2007 (CET)
- Nicht schön, aber wirksam: [5]. --Revolus Echo der Stille 09:50, 21. Nov. 2007 (CET)
- Danke. Ist mir gerade auch aufgefallen und oben eingebaut. --Fomafix 10:00, 21. Nov. 2007 (CET)
- Danke Euch vielmals, der Default-Link klappt im IE zwar weiterhin nicht, aber den habe ich auch nicht vor zu verwenden. --Niteshift 20:25, 21. Nov. 2007 (CET)
- Bei mir klappt irgendwie nur der default-Link, aber die einzelnen Rects nicht. Ich gebe es mal an die Vorlagenwerkstatt weiter. --Revolus Echo der Stille 20:42, 21. Nov. 2007 (CET)
- nur der Default-Link kann sein, da ich nur ein kleines Test-Rechteck am Horizont (Fernsehturm+Sendemast) gesetzt hatte, was auch nicht leicht zu finden ist. In der Form wird das verwendete Bild nie für einen Artikel genutzt werden, so dass ich mir keine Mühe mit den verlinkten Flächen gemacht habe. Der Default-Link funktioniert doch, allerdings wird im IE "Panoramabild Schwerins" anstelle des Linkzieles in der Popup-Info angezeigt. Die Vorlagenwerkstatt muss somit nicht bemüht werden ;). --Niteshift 20:52, 21. Nov. 2007 (CET)
- Hab's auch mit anderen Flächen ausprobiert: Beii mir (mit dem Opera) funktioniert es nicht korrekt. In der Vorlagenwerkstatt ist eh nichts los im Moment, da kann man schon eine kleine Bitte stellen :-) --Revolus Echo der Stille 20:59, 21. Nov. 2007 (CET)
- nur der Default-Link kann sein, da ich nur ein kleines Test-Rechteck am Horizont (Fernsehturm+Sendemast) gesetzt hatte, was auch nicht leicht zu finden ist. In der Form wird das verwendete Bild nie für einen Artikel genutzt werden, so dass ich mir keine Mühe mit den verlinkten Flächen gemacht habe. Der Default-Link funktioniert doch, allerdings wird im IE "Panoramabild Schwerins" anstelle des Linkzieles in der Popup-Info angezeigt. Die Vorlagenwerkstatt muss somit nicht bemüht werden ;). --Niteshift 20:52, 21. Nov. 2007 (CET)
- Bei mir klappt irgendwie nur der default-Link, aber die einzelnen Rects nicht. Ich gebe es mal an die Vorlagenwerkstatt weiter. --Revolus Echo der Stille 20:42, 21. Nov. 2007 (CET)
- Danke Euch vielmals, der Default-Link klappt im IE zwar weiterhin nicht, aber den habe ich auch nicht vor zu verwenden. --Niteshift 20:25, 21. Nov. 2007 (CET)
- Okay, mit der Vorlage:Große Imagemap funktioniert es jetzt und ich habe die Beschreibung erweitert. --Revolus Echo der Stille
@Revolus: Du hast bei der Vorlage:Große Imagemap ein weiteres div
mit text-align:left
und width:100%
eingefügt. Das text-align:left
ist sinnvoll, weil sonst der blaue Infokreis außerhalb des Bildes ist, wenn das Bild kleiner als das Browserfenster ist. Ich habe es daher in mein obiges Beispiel eingebaut. Das zusätzliche width:100%
kann ich nicht nachvollziehen. Durch das width:100%
wird der rechte Rahmen bei Opera und Firefox geringfügig schmaler. Der Internet Explorer benötigt ein width:100%
, aber das ist bereits in dem inneren div
enthalten. Wenn niemand mit der folgenden Darstellung Probleme hat werde ich das zusätzliche div
wieder entfernen und das text-align:left
in das innere div
einbauen. --Fomafix 17:53, 25. Nov. 2007 (CET)
- Entfernt. --Revolus Echo der Stille 07:39, 26. Nov. 2007 (CET)
- Danke. Da nun zusätzlich der FixPng-Workaround für den Internet Explorer aktiviert ist, hat der blaue Kreis auch kein störendes weißes Quadrat außen rum. --Fomafix 09:40, 26. Nov. 2007 (CET)
Hallo, ich wollte mal ein bisschen Werbung hierfür machen: Wikipedia:Fragen zur Wikipedia#Umfrage: Aktivierung einer MediaWiki-Erweiterung zur Auswertung von Parametern u/o Parserausdrücken in XML-Tag --Revolus Echo der Stille 17:34, 5. Jan. 2008 (CET)
Keine Bilder am Artikelanfang
Bei mir wurden schon Bilder vom Artikelanfang weiter nach hinten gesetzt hinter die Artikeleinleitung. Die Begründung war daß Menschen welche auf eine Lesehilfe angewiesen sind wie z.B. Blinde gleich Text vorgelesen bekommen während sie bei einem Bild am Anfang erst warten müssen bis das Bild hoch geladen ist. Dies leuchtet mir ein daher denke ich es wäre sinnvoll dies als Hinweis hier mit aufzunehmen. Gegebenenfalls könnte ein Baustein mit entsprechendem Hinweis bei neu hinzugekommenen Bildern auf den Benutzerseiten der einfügenden Benutzer diese dazu veranlassen dies in Zukunft immer so zu tun. ich werde mich jedenfalls in Zukunft danach verhalten und auch in bestehenden Seiten dies entsprechend ändern. Mit freundlichen Grüßen --Ronaldo 13:21, 1. Nov. 2007 (CET)
- Es gibt inzwischen ein Gadget, das Bilder vom Artikelanfang hinter die Einleitung verschiebt, siehe Wikipedia:BIENE/Blinde. Es ist damit nicht mehr nötig, die Artikel aus Rücksicht auf blinde Benutzer für alle sehenden Benutzer zu verschlechtern. --TM 12:41, 19. Feb. 2008 (CET)
- Danke für den Hinweis. Mit freundlichen Grüßen -- Ronaldo 10:28, 11. Apr. 2008 (CEST)
- Diese Hilfsfunktion für sehbehinderte Leser sollte Autoren doch etwas bekannter gemacht werden, ich habe bislang auch öfters Bilder ein Stückchen nach unten verschoben, genau wegen der Lesbarkeit, und bin jetzt nur per Zufall auf diesen Hinweis hier gestoßen, daß das überflüssig ist. -- Smial 11:23, 11. Apr. 2008 (CEST)
- Danke für den Hinweis. Mit freundlichen Grüßen -- Ronaldo 10:28, 11. Apr. 2008 (CEST)
Finden geeigneter Bilder
Hier fehlt IMO eine kurze Anleitung, wie man bereits vorhandene Bilder zu einem Thema findet. --217.186.129.147 06:40, 7. Dez. 2007 (CET)
- Warum wird beim Hochladen auf de.WP eigentlich nicht automatisch die Eingabe einer Kategorie verlangt? Gruss, --Markus 14:14, 11. Mär. 2008 (CET)
- Ich hatte schon zig Bilderkategorien auf WP.de angelegt die aber alle wieder gelöscht wurden mit der Begründung daß alle Bilder auf Commons hochgeladen werden sollen. Meiner Ansicht nach gehen dadurch alle auf WP.de hochgeladenen Bilder für eine sinnvolle Nutzung verloren was scheinbar auch so gewollt ist. Außerdem können auch nicht alle Bilder auf commons hochgeladen werden wegen diverser gesetzlicher bestimmungen. Finden von Bildern ist hier somit ein Glücksspiel. Mit freundlichen Grüßen -- Ronaldo 11:29, 11. Apr. 2008 (CEST)
- 2008 -
Ratlos!
Bin gerade völlig ratlos. Habe im Artikel Marie Takvam nur einen Hinweis auf IMDb eingefügt (siehe Weblinks); und jetzt steht da: "Dieses Beispielbild gehört nicht in Artikel! Bitte entferne es!" Aber erstens weiß ich nicht, wie dieser Hinweis da hingekommen ist, und noch weniger, wie sich das angebliche Bild entfernen lässt. Info schon mal vorweg: Habe von solchen Dingen nicht die geringste Ahnung; vielleicht ist es nur eine Kleinigkeit, die ich einfach nicht sehe. Bin dankbar für Eure Hilfe. --Happolati 09:37, 31. Jan. 2008 (CET)
- Ich habe deinen Fehler behoben. Du hast wohl aus Versehen auf das Bild-Icon in der Werkzeugleiste oberhalb vom Bearbeiten-Fenster geklickt. Dadurch wird das Format für ein Bild eingefügt. — Raymond Disk. Bew. 09:55, 31. Jan. 2008 (CET)
Besten Dank! Und ich habe immer nur an den Weblinks herumgetüftelt :-) --Happolati 09:58, 31. Jan. 2008 (CET)
Großes Bild neben kleinem Text-Absatz
-
Mathematikwürfel
-
Farbenwürfel des Spieles Babylonia
-
Würfel mit Symbolen
-
Letra Mix
Hallo allerseits!
In einem Artikel (Spielwürfel, Kapitel Ander Aufdrucke) wollte ich zu zwei kleinen Text-Absätzen jeweils ein Bild einbinden. Jedoch sind die Bilder größer als der Text lang ist. In der älteren Version von heute, 0:17 sah das dann so aus, dass neben meinem ersten Bild (das dritte im Kapitel, Farbwürfel von Babylonia) bereits beide betreffenden Abätze (zu Babylonia und Letra Mix]] standen, neben meinem zweiten Bild (Buchstabenwürfel Letra Mix) dann nichts weiter. Demnach passte aber auch der Inhalt des Letra Mix-Absatzes nicht zum nebenstehenden Bild.
Nun die große Frage: Wie kann ich es hin bekommen, dass zwischen dem Babylonia- und dem LetraMix-Absatz so viel Abstand ist, dass die Absätze mit den nebenstehenden Bildern korrespondieren?
Klar, ich kann eine Tabelle bauen. Aber das ist wohl kaum im Sinne des Erfinders.
Schönen Gruß und vielen Dank für Eure Tipps
--Tolukra 09:00, 4. Februar 2008 (CEST)
- Ich habe es in dem betreffenden Artikel mit thumbs in halber Größe ausprobiert, was aber auch nicht recht paßte. Jetzt mal Gallery genommen, schau es dir an, ob das ok ist. -- Smial 11:03, 4. Feb. 2008 (CET)
- Ich weiß ja nicht, wie's den anderen geht, aber mich persönlich begeistert's so leider nicht. Fand's mit den daneben stehenden Bildern sprechender.
- Aber dennoch schon mal vielen Dank für's mit Grübeln.
- --Tolukra 11:22, 4. Februar 2008 (CEST)
- Mit Galerien bin ich auch nicht glücklich. Alternative wäre eine Tabelle nach nebenstehendem Muster. -- Smial 11:36, 4. Feb. 2008 (CET)
- Wie wäre es mit einer Galerie am rechten Rand? --Fomafix 12:42, 4. Feb. 2008 (CET)
- Statt Tabelle bietet sich auch
clear:none
an, das es leider nicht als direkten Parameter für Bilder gibt. --Fomafix 12:42, 4. Feb. 2008 (CET)
- Mit Galerien bin ich auch nicht glücklich. Alternative wäre eine Tabelle nach nebenstehendem Muster. -- Smial 11:36, 4. Feb. 2008 (CET)
- Ich weiß ja nicht, wie's den anderen geht, aber mich persönlich begeistert's so leider nicht. Fand's mit den daneben stehenden Bildern sprechender.
- Oh clear none gefällt mir abgesehen von der Tipparbeit sehr gut. Gleich mal merken. (Testweise die Rechterrandgalerie mal verkleinert) -- Smial 13:34, 4. Feb. 2008 (CET)
- Ich mach so etwas mit einem erzwungenen Zeilenumbruch <br style="clear:both;" /> siehe Artikel Treppe. Mit freundlichen Grüßen-- Ronaldo 13:52, 4. Feb. 2008 (CET)
- Tja, die Ergänzung im Würfelartikel war wohl nicht so beliebt. Manche Artikel werden anscheinend mit Zähnen und Klauen gegen jede Änderung verteidigt. -- Smial 14:49, 4. Feb. 2008 (CET)
Bilder im Absatz ausrichten - Unterschied IE / Firefox
Ich versuche gerade ein neues Portal für Frankreich zu erstellen. Infolge der Gliederung in Tabellen werden einzelne Spalten recht schmal. Nun ist das im IE kein größeres Problem, da eingebundene Bilder problemlos vom Text umflossen werden. Allerdings tritt bei mir im Firefox (Version 2.0.0.11) das Problem auf, dass der Text eines ganzen Absatz neben dem Bild bleibt, und daher unterhalb der Abbildung so ein unschöner leerer Raum bleibt. Lässt sich dieses irgendwie beheben? (Siehe hier (Block Verkehr). Danke für die Hilfe --Patrick, «Disk» «V» 13:35, 6. Jan. 2008 (CET)
- Komische Sache. Bei mir wird alles ganz normal umflossen. Soweit ich das sehen kann, hast du aber alles richtig gemacht, deshalb wundert mich das schon etwas. --Revolus Echo der Stille 15:23, 6. Jan. 2008 (CET)
- Mir ist auch gerade ein Problem mit Firefox aufgefallen: auf Sowjetunion#Gliederung überlappt das Bild die weiter unten stehende Tabelle. -- Rita2008 19:21, 18. Feb. 2008 (CET)
Galerie und Infobox
Beim Firefox kann es zu einer Überlagerung einer Galerie mit einer Infobox am rechten Rand kommen. Internet Explorer und Opera sind nicht davon betroffen. Dort wird die Galerie automatisch nach unten verschoben, sobald der Platz in der Breite nicht mehr ausreicht.
Infobox
-
Rotkehlchen
-
Gänse
-
Komodowaran
-
Hauskatze
Beim Firefox kann nachgeholfen werden, um dieses Verhalten auch zu erreichen:
Infobox
-
Rotkehlchen
-
Gänse
-
Komodowaran
-
Hauskatze
Ich habe dazu die Galerie mit style="float:left"
ergänzt. Den nachfolgenden Absatz muss ich aber mit style="clear:left"
zurückgesetzt werden.
Eine automatische Ergänzung von style="float:left"
bei allen Galerien ist problematisch. Ich bin gerade mit folgendem am testen:
table.gallery { float:left }
table.gallery + * { clear:left }
Es funktioniert meist, hat aber Probleme, wenn das nächste Objekt kein Absatz, sondern selbst ein Fließobjekt ist.
In Einzelfällen mag das aber geeignet sein, um Darstellungsfehler zu vermeiden: [6], [7] --Fomafix 09:27, 7. Feb. 2008 (CET)
- „Es funktioniert meist“ ist eine ganz schlechte Vorraussetzung dafür, solche Änderungen in die offiziellen CSS-Definitionen der Wikipedia zu übernehmen. Vor allem, wenn es sich offenbar gar nicht um ein Problem der Wikipedia sondern um ein Problem des Firefox handelt. Ich zweifle auch an der Sinnhaftigkeit dieses Vorschlags: Warum sollte man den Galerien eine float-Eigenschaft geben, wenn sie gar nicht von den nachfolgenden Elementen umflossen werden sollen? --TM 20:01, 24. Feb. 2008 (CET)
- Meine oben genannte CSS-Definition ist definitiv nicht als Standarddefinition für Wikipedia geeignet. Fakt ist aber, dass der Firefox Probleme hat und die von Autoren mit schlechten Workarounds umgangen werden: [8] [9]. Bei solchen Fällen eignet sich oben beschriebenes Verfahren mit
<gallery style="float:left">
und nachfolgendemclear
. Mit diesem Workaround entstehen keine Nachteile durch zusätzliche große weiße Flächen. --Fomafix 20:29, 24. Feb. 2008 (CET)
- Meine oben genannte CSS-Definition ist definitiv nicht als Standarddefinition für Wikipedia geeignet. Fakt ist aber, dass der Firefox Probleme hat und die von Autoren mit schlechten Workarounds umgangen werden: [8] [9]. Bei solchen Fällen eignet sich oben beschriebenes Verfahren mit
Cover-Bilder einbinden?
Ich schreibe gerade ein paar Artikel zu Musik-Songs. Auf der englischen Wikipedia sind in den Artikeln die Cover dazu eingebunden. Kann ich das im Deutschen Wiki auch machen? --Djmirko 18:37, 26. Feb. 2008 (CET)
- Solche Fragen stellst du am besten bei Wikipedia:Urheberrechtsfragen. Kurze Antwort: Hier in der deutschsprachigen Wikipedia ist das Hochladen von Covern grundsätzlich verboten, von einigen wenigen Ausnahmen abgesehen (erteilte Freigabe oder fehlende Schöpfungshöhe). Siehe dazu Wikipedia:Bildrechte. --TM 09:28, 27. Feb. 2008 (CET)
Bildunterschriften
Hallo!
Ich hatte hier einen kleinen Disput mit Axel.Mauruszat bezüglich der Zentrierung von Bildunterschriften. Nun ist mir wohl bekannt, dass in den meisten Wikipedia-Artikeln Bilderklärungen unter den eingebundenen thumbs linksbündig formatiert werden. Begründet wird das scheinbar mit einer feststehenden Regel zur Textgestaltung:
"Formatierungen, die nicht in normalen Wikipedia-Artikeln verwendet werden sollten ... <center>zentriert</center>"
Ich kann nicht nachvollziehen, warum diese Regel stringent auf Bildunterschriften Anwendung finden soll, zumal auch bei Einbindung von Bildern in "Info-Boxen" und "großen Bildern" (siehe oben bei "Panoramabild Schwerins") eine automatische Zentrierung der Bilderklärungen erfolgt.
Man sollte doch darauf achten, dass auch nichtangemeldeten Benutzern (ohne Möglichkeit irgendwelcher Einstellungsoptionen) ein ansprechendes Layout der Artikelseiten der Wikipedia geboten wird. Dazu gehört meines Erachtens auch eine entsprechend gefällige Bilddarstellung.
Wäre es deshalb möglich, eine entsprechende Regel aufzunehmen, die es gestattet, Bildunterschriften zentriert darzustellen? Zumindest aber eine, die es den Autoren von Artikeln überlässt, dies bei der Artikelgestaltung selbst zu entscheiden? Gruß --Oltau 19:17, 24. Feb. 2008 (CET)
- Schlichte Antwort: Nein. Solche „Layoutspielereien“ sind kontraproduktiv. Die genannte Regel zur Textgestaltung ist dabei gar nicht das ausschlaggebende Argument. Der wichtigste Aspekt der Gestaltungsregeln hier in der Wikipedia ist, dass die Artikel einheitlich aussehen. Wenn ein Benutzer (wie du) anfängt, willkürlich irgend welche Bildunterschriften mit
<center>
zu zentrieren, entsteht ein wildes Durcheinander, das niemand mehr durchschaut. Wenn überhaupt, dann müssten alle Bildunterschriften zentriert werden. Das darf aber niemals durch Einfügen irgendwelcher HTML-Spielereien geschehen sondern muss zentral an der richtigen Stelle geändert werden, nämlich im Stylesheet main.css (dort, wo jetzttext-align: left;
steht). Es steht dir frei, diese Änderung vorzuschlagen – Argumente, die dafür sprechen würden, hast du ja schon genannt. --TM 19:53, 24. Feb. 2008 (CET)- Und wo diskutiert man sowas oder schlägt dies vor? --Oltau 20:23, 24. Feb. 2008 (CET)
Zentrierte Bildunterschriften haben ein Problem bei der Ausrichtung, wenn der Text mehrzeilig wird, wie rechts zu sehen ist. Eine generelle Aktivierung von zentrierten Bildunterschriften würde die Darstellung bei einigen Artikeln verschlechtern. --Fomafix 20:37, 24. Feb. 2008 (CET)
- Und bei vielen verbessern. Dein Beispiel ist mir bekannt. Doch setzt doch niemand mehrere kurze Wörter untereinander. Normalerweise ist die erste Reihe voll, dann folgen die nächsten gleichmäßig zentriert. --Oltau 20:42, 24. Feb. 2008 (CET)
- Diese Diskussion ist sinnlos und hier wie schon betont deplatziert. Es wird keine zentrierten Bildunterschriften geben. Du glaubst es vielleicht nicht, aber du bist nicht der erste, der auf diese Idee gekommen ist. Die Bildunterschriften sind ja nicht „aus Versehen“ linksbündig. Das hat man sich damals, als das so entschieden wurde, gut überlegt. Dabei wurde auch die Möglichkeit der Zentrierung in Betracht gezogen – und verworfen. Also lass es bitte. --TM 20:48, 24. Feb. 2008 (CET)
Zunächst rät man mir oben, das anderweitig anzusprechen (wo, weiß ich immer noch nicht), dann bekommt man eine solche Abfuhr. Ich will doch hier keine Spiegelschrift oder farbige Buchstaben einführen! Mir geht`s um eine bessere Ansicht (auch für nichtangemeldete Benutzer). Was schadet es übrigens bei aller Einheitlichkeit, dass einige Artikel "besser" aussehen, bei der Unterschiedlichkeit, die die Artikel im Allgemeinen vermitteln? Schließlich bemühe ich mich andernorts auch um vereinheitlichte Strukturen der Artikel, wo ich das für angebracht halte. Gruß --Oltau 10:24, 27. Feb. 2008 (CET)
- Es gibt keinen großen Unterschied zwischen farbiger oder zentrierter Schrift. Beides ist Geschmackssache. Dir gefällt das, anderen Benutzern gefällt es nicht. Wenn du Wert darauf legst, füge die Zeile
.thumbcaption { text-align: center; }
in deine monobook.css ein. Falls du das tatsächlich weiter diskutieren möchtest, wäre hier in der deutschsprachigen Wikipedia wahrscheinlich MediaWiki Diskussion:Common.css die beste Stelle. --TM 17:33, 27. Feb. 2008 (CET)
Höflich?
ist es höflich, größere Eingriffe auf der Diskussionsseite vorzuschlagen und nicht einfach zu vollziehen. Verstöst aber gegen das Grundprinzip: "Sei mutig" und editiere, wenn es sinvoll ist. Die Wikipedia ist nicht zum Austausch von Höflichkeiten da, was der Wikipedia dient, ist immer erlaubt.--85.178.21.153 15:38, 28. Feb. 2008 (CET)
- Und was möchtest du uns jetzt damit sagen? Hast du eine größere Änderung geplant, die viele vor den Kopf stoßen könnte?
- Das Regelwerk der Wikipedia ist in vielen Fällen mehrdeutig, nicht für jede mögliche Situation gibt es genau eine korrekte Anweisung/Regel/Vorschrift/Norm. Was spricht gegen Höflichkeit? 85.177.176.86 16:44, 28. Feb. 2008 (CET)
Bilder von Commons, wenn gleicher Name schon vorhanden ist
Kann man ein Bild von den Commons einbinden, wenn ein gleichnamiges in der deutschen Wikipedia vorhanden ist? Ein Hinweis auf der Hilfeseite wäre gut, ob das geht, und wenn ja, wie. Kann man auch Bilder von anderen Wikipedien einbinden und was ist dabei zu beachten? (Methode, Lizensierung). --Hutschi
- Nein, das geht nicht. Lokale Bilder werden immer bevorzugt. Falls möglich, sollte das Bild von der de.wp daher nach Commons umziehen. Falls dies aus lizenzrechtlichen Gründen nicht geht, wird man das Bild auf de.wp unter einem neuen Namen neu speichern müssen das alte Bild löschen, damit das Commons-Bild „durchkommt“.
- Bilder aus anderen Wikipedien können nicht eingebunden werden. Nur aus Commons. Auch hier gilt, dass das Bild nach Commons umziehen sollte, falls die Lizenz es zulässt. Siehe auch Hilfe:Dateien auf Commons verschieben. — Raymond Disk. Bew. 18:56, 8. Mär. 2008 (CET)
Mein Problem war, dass ich beim Damensattel nicht bemerkt hatte, dass er als Reitsattel bereits in der deutschen Wikipedia war, als ich ihn in den Commons hochlud. Ich habe jetzt dort das Bild aus der deutschen Wikipedia darübergeladen und ein anderes Wort (Damenfahrradsattel) gewählt. Dabei fiel es mir ja noch auf. Aber: Wenn jemand einen Begriff, der in den Commons schon existiert, in die deutsche Wikipedia als Bild brint, und es ist ein Homonym, dann werden Originalartikel verfälscht, ohne dass der Autor es bemerkt. --Hutschi 09:24, 9. Mär. 2008 (CET)
Bild + Text als Link
Ich suche eine Möglichkeit, ein Bild (Icon) plus Text gemeinsam als Link zu verwenden (also ohne dass das Bild zur Bildbeschreibungsseite linkt), und Icon und Text nebeneinader stehen und eine Art "Block" bilden (also möglichst auch der Zwischenraum anklickbar ist)...
<imagemap> Bild:xy.png|40px default [[Link|Text]] desc none</imagemap> [[Link|Text]]
etwas gebastelt (ohne Erfolg):
<div class="icon"><imagemap> Bild:xy.png|40px default [[Link|Text]] desc none</imagemap> [[Link|Text]]</div>
Optimal wäre, wenn sich der Code in einer Zeile unterbringen liesse. Danke, --Markus 14:24, 11. Mär. 2008 (CET)
- Es geht folgendermaßen:
<div class="imagemap-inline"><imagemap> Bild:Anticopy.svg|30px default [[Link|Copyrightfrei-1]] desc none</imagemap> [[Link|Copyrightfrei]]</div>
- Vielleicht sollte für diesen üblichen Fall eine passende Vorlage erzeugt werden. --Fomafix 16:15, 11. Mär. 2008 (CET)
- Schau dir mal die Hauptseite mit den Links auf die Portale (oben) und die Schwesterprojekte (unten) sowie Vorlage:imagemap an. — Raymond Disk. Bew. 16:18, 11. Mär. 2008 (CET)
Danke Raymond für den Tip mit der Vorlage. Aber irgend etwas mache ich falsch (neuer Versuch, von Hauptseite abgeschaut):
<div style="white-space:nowrap;"><span class="icon">{{subst:Imagemap|Bild=Anticopy.svg|Maße=30px |Ziel=Link|Alt=Link|Titel=Link|Beschreibung=keine}} </span>[[Link|Copyrightfrei-2]] </div>
Und bei mir funktioniert gar nichts... Gruss, --Markus 19:02, 11. Mär. 2008 (CET)
- Welche MediaWiki-Version setzt du ein? #tag kommt erst mit der 1.12. Die Wikipedia rennt aber schon mit 1.13alpha. — Raymond Disk. Bew. 19:32, 11. Mär. 2008 (CET)
- Aufgesetzt am 26.9.2007, Version wo steht die? Gruss, --Markus 19:43, 11. Mär. 2008 (CET)
- unter http://vasv.org/index.php?title=Special:Version . Ich würds ja selber nachschauen, aber ich kanns nicht lesen. — Raymond Disk. Bew. 22:00, 11. Mär. 2008 (CET)
- Version 1.11.0 Gruss, --Markus 22:31, 12. Mär. 2008 (CET)
- unter http://vasv.org/index.php?title=Special:Version . Ich würds ja selber nachschauen, aber ich kanns nicht lesen. — Raymond Disk. Bew. 22:00, 11. Mär. 2008 (CET)
- Aufgesetzt am 26.9.2007, Version wo steht die? Gruss, --Markus 19:43, 11. Mär. 2008 (CET)
Wie bindet man Bilder aus der englischen Wiki ein?
--Zor2112 15:19, 21. Mär. 2008 (CET) zB
Datei:Harry Potter and the Deathly Hallows.jpg
- Grundsätzlich kannst du Bilder, die du aus der englischen Wikipedia übernehmen willst, in die deutsche Wikipedia oder noch besser in Commons hochladen. Das Harry-Potter-Bilder darfst du in der deutschen Wikipedia allerdings gar nicht verwenden, da die Lizenz „fair use“ nicht reicht, siehe Wikipedia:Bildrechte.-- MSchnitzler2000 17:54, 21. Mär. 2008 (CET)
Bilder im Absatz ausrichten - was ist gut, was nicht?
Hallo Wikipedianer, ich brauche mal eure Hilfe: Bei dem Artikel zur Glaubenskirche hatte ich beide thumbnails auf 150px begrenzt, um zu erreichen, dass die thumbs nicht über den Strich zum nächsten Absatz hinausreichen. Außerdem finde ich, dass das erste thumbnail bei der kurzen Artikeleinleitung überdimensioniert wirkt. Meine Änderung wurde nun wieder rückgängig gemacht. Begründung: Bildformate wieder nach Standard (ohne feste Größe, Eingangsbild größer, ohne unnötige Leerräume). Nun meine Fragen:
- Ist der Standard auch irgendwo schriftlich fixiert? Unter Wikipedia:Bilder#Das_Bild_nicht_umfließen steht zwar, wie das mit der Absatzausrichtung geht, aber leider steht dort nicht, ob dies auch Wiki-Standard, bzw. gewünscht ist.
- Ist Größenbegrenzung für thumbnails sinnvoll oder eher nicht erwünscht? Wenn sinnvoll, zu welchen Zwecken?
- Gibt es eine Liste mit Erklärungen für css-Anweisungen und Hinweisen für Dummies wie mich? Was bewirkt z.B. die Anweisung upright=1.3 und warum ist dies Standard und eine Pixelbegrenzung nicht?
- Sollen thumbnails in den nächsten Absatz hineinragen, oder soll man diese ausrichten? Mit welchen Anweisungen?
- Thumbnails immer rechts im Text ausrichten? Nur manchmal? Wann ist manchmal?
Fragen über Fragen – Ich hoffe, ihr könnt mir helfen. Ein weiteres Beispiel, in dem alle meine "Bildprobleme" zu Tage treten ist der Artikel Roedeliusplatz. Tipps hierzu sind ausdrücklich erwünscht! :-) Danke im Voraus für eure Hilfe: --Rage71 12:10, 27. Mär. 2008 (CET)
- Du schneidest das Perspektivitätsdilemma an. Nun gut, haben wir im reellen Leben nicht persönliche Perspektiven? Warum sollen Wir nicht bei dieser Darstellungsfrage freimütig sein? Braucht es da eine Norm? --81.62.137.67 11:59, 29. Mär. 2008 (CET)
- Ich brauche Sie nicht unbedingt. Ich kann aber nicht verstehen, warum andere die "bessere" Perspektive haben sollten und Dinge revertieren, über die ich mir lange Gedanken gemacht habe. --Rage71 13:14, 29. Mär. 2008 (CET)
- Es gibt eine Seite Hilfe:Bilder in der steht was mit Bildern so alles gemacht werden kann. Auch ich habe mich damit befasst und versucht Artikel so zu gestallten daß etwas sinnvolles dabei herauskam. Leider hat man mir oft genug meine Bemühungen zerstört indem man auf polices verwiesen hat deren existenz mir bis heute nicht klar ist. Es scheint hier so dass es einige Leute gibt die dürfen tun und lassen was sie wollen und interessieren sich nicht dafür wieso und warum jemand in einem Artikel etwas gemacht hat was durchaus Sinn hatte. Du wirst damit leben müssen daß es immer wieder welche gibt die all deine Denkarbeit zerstören oder du gibst auf hier Artikel zu schreiben so wie ich das getan habe. Mit freundlichen Grüßen -- Ronaldo 08:54, 30. Mär. 2008 (CEST)
- Ich brauche Sie nicht unbedingt. Ich kann aber nicht verstehen, warum andere die "bessere" Perspektive haben sollten und Dinge revertieren, über die ich mir lange Gedanken gemacht habe. --Rage71 13:14, 29. Mär. 2008 (CET)
- Du sprichst einige grundsätzliche Layout-Fragen an. Erstmal: Wir haben hier html und nicht flash. Das bedeutet, daß die Darstellung eines Artikels auf dem Bildschirm des Benutzers letzlich vom verwendeten Browser, den Bildschirmeinstellungen und den Präferenzen des Benutzers abhängig ist. Versuche, ein ganz bestimmtes, festgelegtes Layout zu erzwingen, sind deshalb von vorneherien zum Scheitern verurteilt, und das ist auch gut so. Auf Hilfe:Bilder bist du ja schon hingewiesen worden.
Eine Größenbegrenzung oder besser: Eine vom Standard abweichende Skalierung kann durchaus sinnvoll sein. Eine Fixierung auf eine ganz bestimmte Pixelbreite ist jedoch in den meisten Fällen böse: Der eine Nutzer hat ein ältliches Notbuch mit 1024*768er Bild - ein Festnageln von Bildern auf 400px Breite pflastert dem den Bildschirm zu. Der nächste werkelt mit nem 1920er Wide-Screen-Monitor und hat in seinen Benutzereinstellungen die Standardgröße auf 300px Breite eingestellt, weil ihm sonst die Darstellung doch zu sehr in Briefmarkengrößennähe rückt - dem setzt du mit einer Skalierung auf 130px eine noch kleinere Briefmarke vor. Unvermeidlich sind feste Skalierungen beispielsweise in Taxoboxen, weil sonst das Tabellenlayout verwürfelt wird.
Um nun trotzdem Bildgrößen relativ zueinander ändern zu können, wurde der upright-Parameter eingeführt. Der plutimiziert die vom Benutzer eingestellte Standardgröße mit dem angegebenen Faktor. "upright" heißt der (gewissermaßen traditionell), weil er in der Standardeinstellung (also ohne Angabe eines Faktors) dafür sorgt, daß hochformatige Bilder relativ zu querformatigen nicht übermäßig groß dargestellt werden. "upright" sollte auch mit Faktor in der Regel dazu verwendet werden, Hochformate gegenüber dem Standerd zu verkleinern. Eine Angabe größer 1, also z.B. deine 1.3 macht ein Bild gegenüber dem Standard 30% größer. Das kann manchmal nützlich sein, wenn in einer Grafik Schriften enthalten sind, die man in Standardthumbgröße (180px) schlecht erkennen kann.
Vorteil: Die Größenverhältnisse zwischen den einzelnen thumbs bleiben bei jeder vom Leser eingestellten persönlichen Einstellung erhalten. Der Widescreen-Freund sieht also bei einem Bild mit upright=0.5 unter einem Thumb ohne solche Angabe immer ein halb so großes Bild. Bei einer Festlegung auf 130px ändert sich das Verhältnis, je nachdem, was der User bei sich als Standard eingestellt hat - und das ist das genaue Gegenteil davon, was du eigentlich mit diesem Layout-Versuch erreichen wolltest.
Ein Hereinragen in den Folgeabsatz ist meines Wissens nur mit {{subst:Absatz}} zu verhindern. Nachteil: Je nach Textverteilung und Fenstergröße kann das sehr große, hässliche Textlücken erzeugen.
Standardausrichtung ist rechts, weil dann die Zeilen links immer auf derselben Linie beginnen, das erleichtert flüssiges Lesen. Nimm beliebige Druckwerke, rechtsbündige oder zentrierte Texte mit zerfranstem linken Rand sind (für einen Leser, der europäische Schreibweisen gewohnt ist) mühsamer zu lesen. Es ist kein Zwang, alles rechts auszurichten, aber empfehlenswert. -- Smial 12:12, 30. Mär. 2008 (CEST)
- Hallo Smial, vielen Dank für deine ausführliche Hilfe. Meine Richtschnur wird also lauten, künftig möglichst auf Größenoptionen zur Absatzausrichtung zu verzichten.
- Aber auch Ronaldo spricht mir aus dem Herzen. Da arbeitet man stundenlang und zerbricht sich den Kopf und dann wird mit einem Federstrich Alles wieder revertiert. Leider stärkt das nicht immer die Motivation, zumal wenn nicht oder unfreundlich begründet wird. Schön aber, dass es auch Wikipedianer gibt, die das Gespräch suchen und denen Konsens etwas bedeutet. Dann klappts auch schnell wieder mit der Motivation. --Rage71 23:24, 30. Mär. 2008 (CEST)
- Revertierungen ohne jegliche Begründung, selbst wenn sie sachlich gerechtfertigt sind, halte ich für sehr unhöflich. Klar, daß das demotivierend wirkt, wenn man eigentlich mit guten Absichten rangegangen ist. Bedenke aber auch: Möglicherweise hat in der Vergangenheit bereits eine Diskussion über eine sehr ähnliche Änderung stattgefunden und unter den bisherigen Artikelautoiren hat sich bereits ein Konsens über die Gestaltung herausgebildet, den du über den Haufen wirfst. Wenn dir also ein Revert unverständlich ist, lohnt sich immer ein Blick in die Artikelhistorie und auf die zugehörige Diskussionsseite - eventuell findest du dort den Grund. Auf der Disk kannst und solltest du auch größere Änderungen eventuell vorher ansprechen. Auch lohnt sich oft eine Nachfrage beim Revertierenden, wenn du dort deine Argumente sachlich vorträgst, solltest du normalerweise eine genauere Erklärung bekommen - oder aber einen neuen Konsens finden. -- Smial 00:37, 31. Mär. 2008 (CEST)
Bilder im Viertel-Maß drehen, spiegeln oder Ausschnitte definieren
Wie kann ich ein Bild per Angabe im Referenzierungs-Code um 90°, 180° oder 270° drehen? Kann man Bilder spiegeln lassen? Ist es möglich einen Ausschnitt aus dem Original zu definieren? Das müsste doch alles eigentlich eine Kleinigkeit für den sowieso oftmals bemühten Thumbnail- und Skalierungs-Code in der WP sein. Zumindest spart garantiert das nochmalige, redundante Hochladen und damit Speicher, sowie Aufwand zur mehrfachen Verwaltung ein und der selben Bild-Daten. --Alexander.stohr 18:44, 29. Mär. 2008 (CET)
- All dies wäre mit convert scriptbar, würde aber imho die Parametrierung für die paar Einzelfälle unnötig aufblähen. -- Smial 19:54, 29. Mär. 2008 (CET)
- Hmm, also dann wird es wohl eher keine Erweiterung der Art "rotate-left/right/down", "mirror-leftright/updown" oder "crop-100,150-320x200" geben. Ich hätte da eigentlich keinen besonderen Mehraufwand erwartet, so lange für den Wikipedia-Parser die Schlüsselworte nach dem letzten | enden und dabei evtl. unbekannte Schlüsselworte ignoriert werden. Die Auswertung für die neuen Keywords wäre natürlich zu ergänzen. --Alexander.stohr 14:18, 30. Mär. 2008 (CEST)
- Die richtige Adresse für deinen Wunsch wäre Wikipedia:Verbesserungsvorschläge. Versuch es dort mal. -- Smial 22:57, 30. Mär. 2008 (CEST)
- Hmm, also dann wird es wohl eher keine Erweiterung der Art "rotate-left/right/down", "mirror-leftright/updown" oder "crop-100,150-320x200" geben. Ich hätte da eigentlich keinen besonderen Mehraufwand erwartet, so lange für den Wikipedia-Parser die Schlüsselworte nach dem letzten | enden und dabei evtl. unbekannte Schlüsselworte ignoriert werden. Die Auswertung für die neuen Keywords wäre natürlich zu ergänzen. --Alexander.stohr 14:18, 30. Mär. 2008 (CEST)
Bilder aus Commons
Ich würde gern ein Bild von Commons auf die englische Wikipedia hochladen. Es besteht in der englischen Wikipedia leider ein anderes Bild (anderes Motiv) unter gleichen Namen, so das dieses auf der Seite angezeigt wird. Wie kann ich das Commonsbild hochladen ohne es zu verschieben? -- Carl Steinbeißer 22:35, 29. Mär. 2008 (CET)
- Sinnvoller ist normalerweise, das Bild aus EN unter anderem Namen nach commons zu schieben und die Links entsprechend anzupassen. -- Smial 00:13, 30. Mär. 2008 (CET)
- siehe auch Hilfe_Diskussion:Bilder#Bilder von Commons, wenn gleicher Name schon vorhanden ist - sieht wohl etwas limitiert aus. Wie ist der "schnellste Weg" zum Umziehen eines nationalen WP Bilds auf Commons? Eine Verschieben-Funktion, wie bei Artikeln möglich, scheint wohl nicht bereit zu stehen. Würde ich aber gerne anregen. Das was in den meisten WPs an Bildern existiert ist doch in der Regel eher aus Versehen da gelandet weil es der jeweilige Bild-Einsteller nicht besser wusste, was die optimale Hochladeseite angeht. --Alexander.stohr 14:24, 30. Mär. 2008 (CEST)
- Schau mal hier -- Smial 22:49, 30. Mär. 2008 (CEST)
- siehe auch Hilfe_Diskussion:Bilder#Bilder von Commons, wenn gleicher Name schon vorhanden ist - sieht wohl etwas limitiert aus. Wie ist der "schnellste Weg" zum Umziehen eines nationalen WP Bilds auf Commons? Eine Verschieben-Funktion, wie bei Artikeln möglich, scheint wohl nicht bereit zu stehen. Würde ich aber gerne anregen. Das was in den meisten WPs an Bildern existiert ist doch in der Regel eher aus Versehen da gelandet weil es der jeweilige Bild-Einsteller nicht besser wusste, was die optimale Hochladeseite angeht. --Alexander.stohr 14:24, 30. Mär. 2008 (CEST)
Neues Einloggen beim Hochladen von Bildern nötig ?
Ist es eigentlich normal, dass ich mich vor dem Hochladen auf die Commens wiederholt anmelden muss? Gut, einen Namen und ein Passwort einzugeben ist nicht die Welt. Ich frage hauptsächlich deshalb, weil das erneute Anmelden bei mir in 90% der Fälle nicht klappt. Es wird mir sogar immer gesagt, dass der Benutzer (unter dem ich bereits in dem Augenblick arbeite!) nicht existiert !! So macht das Ganze dann irgendwie keinen Spaß. Mache ich irgendetwas falsch oder oder ein (bekannter?) Wiki-Bug? :-(--N-Lange.de 17:53, 30. Mär. 2008 (CEST)
- Das Häkchen bei "Benutzer dauerhaft anmelden" hast du gesetzt? -- Smial 22:59, 30. Mär. 2008 (CEST)
ich weiß nicht genau wie diese automatische Bildprüfung und löschung funktioniert. Aber entweder sie ist im Moment nicht aktiv oder sie ist ziemlich verbesserungsbedürftig; bei Bild:KrakowskiePrzedmiescieWarsaw.jpg gibt es weder eine Quelle noch einen Autor noch sonst irgendeine Info in der Vorlage:Information. Einzig eine Lizenz wurde ausgewählt. ... Ich will das Bild nicht gleich versenken; wäre schön wenn sich jmd. der weiß was zu tun ist dies entsprechend tut ...Sicherlich Post 23:55, 10. Apr. 2008 (CEST)
- Es gibt keine automatische Bildprüfung und Löschung. Wenn dieses Bild von den in der (Bild-)Eingangskontrolle üblicherweise Tätigen übersehen wurde und niemand den Baustein {{DÜP}} gesetzt hat - feel free, das darf jeder, der sowas entdeckt. DÜP ist auch kein Löschantrag, sondern als Rettungstool gedacht. -- Smial 08:18, 11. Apr. 2008 (CEST)
Bilder der chinesischen Wiki in einen deutschen Artikel einbinden
Ich würde gerne Bilder aus einem chinesischen Artikel in den deutschen einbinden, dies funktioniert jedoch nicht.
Der deutschsprachige Artikel Fuwa enthält schöne Erklärungen, leider keine Bilder. Das chinesische Äquivalent [10] enthält die notwendigen Bilder, z. B. beibei.jpg. In der indonesischen Fassung sind diese Bilder ebenfalls vorhanden, allerdings unter einem anderen Dateinamen, nämlich beibei_2008.jpg.
Wie kann man nun die chinesischen Bilder in den deutschen Text einbinden? Netopyr 01:15, 15. Apr. 2008 (CEST)
- Ich kann zwar kein chinesisch, aber auf der Seite zh:Image:Beibei.jpg prangt ein dickes rotes (C) und die Worte „Logo“ und „Trademark“. Entweder ist das ein Fair Use-Äquivalent, dass es im deutschsprachigen Raum nicht gibt, oder sowas wie unser Vorlage:LogoSH. Ich habe aber die gant starke Vermutung, dass wir es hier nicht verwenden können, die richtige Stelle zum Fragen ist jedoch die Projektseite für Urheberrechtsfragen. — Raymond Disk. Bew. 10:27, 15. Apr. 2008 (CEST)
- Erst mal danke! Mein Chinesisch ist bei Weitem nicht ausreichend, um den (c)-Text wirklich zuverlässig zu übersetzen. Irgendwie scheint aber erwähnt, dass die Bilder nur für die Wiki zu verwenden sind. Ich habe die Frage wie von dir vorgeschlagen unter Urheberrechtsfragen gepostet.
- Allerdings bleibt trotzdem die technische Frage offen: Gibt es eine Möglichkeit, Bilder, die in einem Artikel einer anderen Sprache erscheinen, direkt einzubinden, obwohl sie in einem nicht direkt aufrufbaren Bereich wie "http://upload.wikimedia.org/wikipedia/zh/9/95/" gespeichert sind - z. B. bei Übersetzungen von Wiki-Artikeln ins Deutsche ist das notwendig. Netopyr 19:30, 15.04.2008 (CEST)
- Nein, dies ist nicht möglich. Nur Bilder auf Commons können in hiesige Artikel eingebunden werden. Wenn ein Transfer eines Bildes aus rechtlichen Gründen nach Commons, oder im Ausnahmefall direkt hierhin, nicht möglich ist, kann das Bild nicht genutzt werden. — Raymond Disk. Bew. 20:34, 15. Apr. 2008 (CEST)
- Aha, darf/kann/soll man als Autor dann einen direkten Link wie wir hier, also z. B. zh:Image:Beibei.jpg in die deutschen Wiki-Artikel einbauen, evtl. in () nach dem Stichwort, um das schnelle Auffinden dieser Bilder zu erleichtern? Netopyr 20:46, 15.04.2008
- Nein, das ist nicht erwünscht. In solchen Fällen müssen die Artikel leider ohne Bilder auskommen. Sie sind für die deutschsprachige Wikipedia einfach nicht frei verfügbar. — Raymond Disk. Bew. 22:09, 15. Apr. 2008 (CEST)
- Danke.Netopyr 13:33, 16.04.2008
inline-Bilder
Ich habe gerade ein wenig mit verlinkten inline-Bildern herumprobiert und entdeckt, dass der Parser vor jedem div-Tag den letzten Absatz mit einem
abschließt. Das führt dazu, dass trotz des Attributes style="display:inline"
ein Zeilenumbruch vor und nach dem Bild entsteht. Lässt sich das irgendwie umgehen, sodass der Paragraph vor dem div-Tag nicht geschlossen wird? --Zoid 03:02, 16. Apr. 2008 (CEST)
- Leider nicht. Eine Änderung wurde von den Entwicklern vor ein paar Tagen abgelehnt. Wenn du das Bild in einem Blockelement verdendest, kannst du diesem die Klasse "imagemap-inline" zuordnung; alle gekapselten divs bekommen dann display:inline zugeordnet. Gruß, --Revolus Echo der Stille 03:12, 16. Apr. 2008 (CEST)
- Wollte es eigentlich in einer Vorlage verwenden, die selbst inline dargestellt werden muss, also funktioniert das wohl nicht... Schade, trotzdem vielen Dank für deine schnelle Antwort --Zoid 13:09, 16. Apr. 2008 (CEST)
"Bild:" oder "Image:"
Ich habe kürzlich einen Satz hierzu gelöscht, in dem "Bild:" als korrekter Befehl angegeben wurde:
„Hinweis: Wer eine Galerie auf Commons anlegt, muss „Image:…“ schreiben, in der deutschsprachigen Wikipedia sollte der Befehl „Bild:…“ verwendet werden.“
Der erste Halbsatz ist hier überflüssig, weil es keine Commons-Hilfeseite ist, der zweite Halbsatz ist falsch. Die Software hat originär "Image:" als Befehl. Der deutsche Befehl ist eine Art Weiterleitung. Es gab bereits schon einmal eine Diskussion hierüber. Dabei hieß es, daß es völlig unnötig ist, wenn Benutzer statt "Image:" "Bild:" setzen. Das macht nicht nur die Versionsgeschichte unnötig voll, sondern ist auch eine Belastung für's System.
Benutzer:Aka machte diese Änderung rückgängig [11], ohne sie zu begründen. Daher möchte ich das nun hier erläutert und geklärt wissen. --Matt1971 09:38, 15. Apr. 2008 (CEST)
- „Bild“ und „Image“ sind technisch absolut gleichwertig. Eine erhöhte Belastung fürs System ist „Bild“ jedenfalls nicht. Da wir aber in der deutschsprachigen Wikipedia sind, werden im allgemeinen die deutschen Namensraumnamen verwendet. Dies ist für alle besser lesbar und bei einer Suche im Quelltext muss man im Idealfall nur nach „Bild:“ suchen. Änderungen, die einzig und alleine aus einem „Image“ → „Bild“ bestehen, sind aber nach wie vor zu unterlassen, da sie keine Verbesserung bedeuten und eine zusätzliche Version bedeuten. Ich Verbindung mit anderen Bearbeitungen ändere ich aber auch „Image“ → „Bild“.
- Der Hinweis auf der Hilfeseite, dass auf Commons „Image:“ zu verwenden ist, sehe ich als Service/Gedankenstütze. — Raymond Disk. Bew. 10:20, 15. Apr. 2008 (CEST)
- Ich sehe das als Nachteil, wenn Bild und Image zusammen im Quelltext erscheinen oder eben nur "Bild:". Das erschwert die Suche. Zu "Eine erhöhte Belastung fürs System ist „Bild“ jedenfalls nicht" (Raymond) möchte ich anmerken, daß dies dann sehr wohl der Fall ist, wenn ständig umbenannt wird. Es funktioniert eben auch mit „Image:…“. Somit werden ständig neue Versionen eines Artikels geschaffen, die man gar nicht braucht, so meinte ich das. Ich sehe ständig solche Umbenennungen und ehrlich gesagt ist das vertane Zeit, vertaner Speicherplatz, vertane Arbeit und ein Nachteil für die Versionsgeschichten. --Matt1971 10:33, 15. Apr. 2008 (CEST)
- Habe ich in meiner vorherigen Antwort eigentlich auch deutlich geschrieben:
- „Änderungen, die einzig und alleine aus einem „Image“ → „Bild“ bestehen, sind aber nach wie vor zu unterlassen, da sie keine Verbesserung bedeuten und eine zusätzliche Version bedeuten.“
- „… bei einer Suche im Quelltext muss man im Idealfall nur nach „Bild:“ suchen“
- Ist daran etwas undeutlich? — Raymond Disk. Bew. 12:22, 15. Apr. 2008 (CEST)
- Habe ich in meiner vorherigen Antwort eigentlich auch deutlich geschrieben:
- @Raymond: Die Ausführungen sind ja korrekt - bei meiner Anmerkung zu "Eine erhöhte Belastung fürs System ist „Bild“ jedenfalls nicht" kam es zu einem Mißverständis. Also, die Belastung besteht schon, wenn ständig irgendwelche Leute, die nicht mitdenken, „Image:…“ durch „Bild:…“ ersetzen und sonst keine Änderungen vornehmen. Du meintest es allgemein, ich meinte es im Hinblick auf ebensolche Änderungen.
- Ich weiß immer noch nicht, was an meiner Entfernung falsch war. „Muß“ war und ist immer noch schlichtweg unwahr. Ich werde wohl mal Benutzer:Aka kontaktieren, weil er es versäumt hat, seine Aktion zu begründen. Es ist nicht das erste Mal, daß er mir negativ aufgefallen ist (auch wenn er ein guter Fotograf sein mag). --Matt1971 19:37, 15. Apr. 2008 (CEST)
- Ok, das Missverständnis ist geklärt.
- Das „muß“ ist aber korrekt, da auf Commons nur die englischen Namensraumnamen funktionieren. Du kannst auf Commons kein „Bild:“ verwenden. Und weiter heißt es ebenfalls korrekt: „… in der deutschsprachigen Wikipedia sollte der Befehl „Bild:…“ verwendet werden.“ (Hervorhebung durch mich). — Raymond Disk. Bew. 20:09, 15. Apr. 2008 (CEST)
- Aka hat geantwortet, war meinerseits teilweise ein Irrtum.
- Ich sehe jetzt erst diese Diskussion. Ich hatte es ohne Kommentar rückgängig gemacht, weil es offensichtlich falsch war und mich solche komischen falschen Matt1971-Änderungen mit komischen Begründungen manchmal etwas nerven. Hier und in den Commons. Nunja. -- Gruß, aka 18:57, 18. Apr. 2008 (CEST)
Kinoplakat
In der englischen Wikipedia gibt es zu dem Artikel Wall-E [12] ein hübsches Thumb vom Kinoplakat. Kann das in den deutschen Artikel Wall-E übernommen werden oder müßte es neu erarbeitet werden bzw. ist es überhaupt erlaubt? --Aalhuhnsuppe 16:49, 18. Apr. 2008 (CEST)
- Sorry, sollte erst lesen, dann schreiben.--Aalhuhnsuppe 16:55, 18. Apr. 2008 (CEST)
Korrektur des Autors scheint wirkungslos
Mir ist ungeschickterweise bei Einstellung eines der WP zur Verfügung gestellten Bilds (Bild:BlueTitWithForage.jpg) einen Schreibfehler unterlaufen. Nach Hinweis des Urhebers habe ich den Schreibfehler korrigiert (siehe hier). Nach Aussagen des Urhebers zeigt das jedoch keine Wirkung, er findet nach wie vor den falschen Namen vor, auch nach Aktualisierung des Browser-Caches. Könnt ihr mir helfen?--Cactus26 07:14, 13. Mai 2008 (CEST)
- Nein. Die Änderung V -> F ist einwandfrei übernommen worden. Das muß ein lokales Problem beim Browser des Urhebers sein. -- Smial 10:55, 13. Mai 2008 (CEST)
- Ich habe es nun mal mit dem IE selbst ausprobiert. Dieser zeigt tatsächlich (im Ggs. zum Firefox) die alte Version bei der Kopie der deutschen WP an, die Anzeige der Original-Beschreibungsseite ist korrekt. Woran kann das liegen?--Cactus26 20:11, 13. Mai 2008 (CEST)
- Sorry, da bin ich ratlos. -- Smial 21:28, 13. Mai 2008 (CEST)
- Danke für Deinen Support. Ich gebe jetzt auch auf, habe das Bild nun unter neuem Namen hochgeladen (das alte als Duplicate vermerkt) und hoffentlich den Autor nicht verprellt.--Cactus26 06:59, 14. Mai 2008 (CEST)
- Sorry, da bin ich ratlos. -- Smial 21:28, 13. Mai 2008 (CEST)
- Ich habe es nun mal mit dem IE selbst ausprobiert. Dieser zeigt tatsächlich (im Ggs. zum Firefox) die alte Version bei der Kopie der deutschen WP an, die Anzeige der Original-Beschreibungsseite ist korrekt. Woran kann das liegen?--Cactus26 20:11, 13. Mai 2008 (CEST)
SVG Skalierung fehlerhaft?!
Hallo! wird fehlerhaft skaliert - die Pfeilspitzen fehlen. Das unskalierte Bild wird im FF3 jedoch richtig angezeigt... --Jdiemer 09:32, 13. Jun. 2008 (CEST)
- Pfeilspitzen werden bekanntermaßen vom MediaWiki-Renderer nicht richtig dargestellt - wandle bitte die Pfeilspitzen in Pfade um und alles ist paletti. --AFranK99 [Disk.] 15:24, 13. Jun. 2008 (CEST)
- Ok, habe ich gemacht. Wird das irgendwann behoben?
Umfließender Text bei Bildern
Hallo, seit längerem beschäftigt mich die Frage wie ich es schaffe, dass Text Bilder umfließt wenn die Bilder über eine Überschrift hinausgehen. Bsp: KZ Buchenwald#Aufbau des Lagers. Das Bild mit dem Caracho-Weg ragt über die nächste Überschrift "Schutzhaftlager" hinaus, dadurch entsteht eine unschöne Lücke zwischen der Überschrift "Schutzhaftlager" und folgendem Text. Ich mag diese Lücken nicht, weil sie das Erscheinungsbild des Artikels stören. Es ist nicht der erste Artikel wo mir das auffällt. Gibt es einen Weg wie man den Text also unter die Überschrift bekommt, der Text also alle Bilder "umfließt" und nicht umgebrochen wird. Die Vorlage {{subst:Absatz}} ist hier eher kontraproduktiv. Danke für eure Hilfe. --Gotcha! Coautor ? 08:48, 6. Jun. 2008 (CEST)
- Ist ein Darstellungsproblem beim Internet Explorer, bei Firefox ist die Darstellung korrekt. Wie man bei allen Browsern eine von Dir gewünschte (gleiche) Darstellung bekommt, weiß ich allerdings auch nicht. --Oltau 14:24, 6. Jun. 2008 (CEST)
- Frage hier fast völlig vergessen. Danke für die Antwort. Stimmt tatsächlich. Mit Firefox gehts. Mmh immerhin schonmal was. Naja was darstellung von Webseiten im IE/Firefox angeht, da hatte ich auch schon meine Probleme mit. Villeicht findet sich ja irgendwann mal eine einheitliche Darstellung. Danke trotzdem für deine Antwort. --Gotcha! Coautor ? 09:06, 23. Jun. 2008 (CEST)
- Gern geschehen, wenn´s auch nicht weiter hilft ... Gruß, --Oltau 09:11, 23. Jun. 2008 (CEST)
- Frage hier fast völlig vergessen. Danke für die Antwort. Stimmt tatsächlich. Mit Firefox gehts. Mmh immerhin schonmal was. Naja was darstellung von Webseiten im IE/Firefox angeht, da hatte ich auch schon meine Probleme mit. Villeicht findet sich ja irgendwann mal eine einheitliche Darstellung. Danke trotzdem für deine Antwort. --Gotcha! Coautor ? 09:06, 23. Jun. 2008 (CEST)
SVG-Skalierung
Ich weiß nicht, ob die Frage schon mal beantwortet wurde, konnte jetzt nichts dazu finden: Warum skaliert das kleine der beiden SVG hier nicht als thumb, wohl aber in der Gallery? -- Smial 13:14, 28. Apr. 2008 (CEST)
- Sieht jetzt eigentlich ok aus. Vielleicht ein Cache-Problem o.ä.? --AFranK99 [Disk.] 19:51, 11. Mai 2008 (CEST)
- Echt jetzt ok bei dir? In der oberen Tabellenzeile sind die mit "upright" parametrierten Bilders immer noch konstant groß. Komisch das. -- Smial 20:41, 11. Mai 2008 (CEST)
- Ach, jetzt verstehe ich erst, was du meinst. Ne, funktioniert bei mir auch nicht. Ich vermute aber es liegt an der mickrigen "Basisgröße" von 50x50px. Ich denke, thumbs werden nur runter-, nicht hochskaliert. Insofern müsste es helfen, das SVG in anderer Skalierung hochzuladen. --AFranK99 [Disk.] 10:21, 13. Mai 2008 (CEST)
- Danke, klingt plausibel. Also setzt "upright" offensichtlich erst nach der Abfrage "Original kleiner als n*m Pixel?" an und verweigert genau wie die Standardskalierung die Arbeit bzw. wird übersprungen. Wieder was gelernt. Ein vergrößertes SVG hatte ich zwischenzeitlich schon angefertigt, das skaliert dann auch wie erwartet. Ob irgendwo dokumentiert ist, wo die Grenze liegt? 180px * 180px? -- Smial 10:52, 13. Mai 2008 (CEST)
- Ich vermute, die Grenze ist dynamisch, da sich ja jeder die Thumbnails selbst einstellen kann; vor dem Rendern guckt die Software wohl, wie groß das Thumbnail werden soll. IMHO macht es eh keinen großen Sinn, SVGs kleiner als 180px hochzuladen. --AFranK99 [Disk.] 12:44, 13. Mai 2008 (CEST)
- Danke, klingt plausibel. Also setzt "upright" offensichtlich erst nach der Abfrage "Original kleiner als n*m Pixel?" an und verweigert genau wie die Standardskalierung die Arbeit bzw. wird übersprungen. Wieder was gelernt. Ein vergrößertes SVG hatte ich zwischenzeitlich schon angefertigt, das skaliert dann auch wie erwartet. Ob irgendwo dokumentiert ist, wo die Grenze liegt? 180px * 180px? -- Smial 10:52, 13. Mai 2008 (CEST)
- Ach, jetzt verstehe ich erst, was du meinst. Ne, funktioniert bei mir auch nicht. Ich vermute aber es liegt an der mickrigen "Basisgröße" von 50x50px. Ich denke, thumbs werden nur runter-, nicht hochskaliert. Insofern müsste es helfen, das SVG in anderer Skalierung hochzuladen. --AFranK99 [Disk.] 10:21, 13. Mai 2008 (CEST)
- Echt jetzt ok bei dir? In der oberen Tabellenzeile sind die mit "upright" parametrierten Bilders immer noch konstant groß. Komisch das. -- Smial 20:41, 11. Mai 2008 (CEST)
- Etwas Hintergrundwissen: Der Bildparameter upright wurde vor einigen Monaten leicht geändert. Bis dahin gab es keine Möglichkeit, das hässliche Aufblähen sehr kleiner Bilder zu unterbinden (das ist innerhalb von Vorlagen wichtig, weil die Vorlage u. U. nicht wissen kann, wie groß die ihr übergebenen Bilder sind). Jetzt kann man z. B. mit 300px|upright erreichen, dass das Bild nur dann auf 300px skaliert wird, wenn es größer ist, kleinere Bilder bleiben aber unangetastet. Das hier beschriebene Phänomen bedeutet nun, dass vergessen wurde, SVGs aus dieser Sache auszuklammern (bei SVGs gibt es niemals ein „zu groß“). Evtl. sollte ein Bug dafür angelegt werden. --TM 23:41, 27. Jun. 2008 (CEST)
Abweichende Thumbnails
Die Mülltonne geht nicht mehr auf. Und auch ansonsten scheint der Befehl nicht mehr zu funktionieren. Kann das jemand bestätigen - und den entsprechenden Abschnitt im Text dann berichtigen? -- Dietzel65 18:18, 11. Mai 2008 (CEST)
- Ich kann es zumindest bestätigen --André Schöne 15:07, 27. Jun. 2008 (CEST)
- Aber steht ja auch da. Ist ein temporärer Fehler, der auf die Software-Entwicklung zurückzuführen ist --André Schöne 15:10, 27. Jun. 2008 (CEST)
Die Vorlage wird im Artikel Europäische Union für nicht angemeldete Benutzer nicht korrekt angezeigt, statt dessen erscheint die Fehlermeldung
<imagemap>-Fehler: Bild ist ungültig oder nicht vorhanden
Ich kann nicht erkennen, woran das Problem liegt. Beim Aufruf der gleichen Artikelversion über den Permanentlink [13] ist die Darstellung interessanterweise einwandfrei. Hat jemand eine Idee, woran das liegen kann? --FordPrefect42 18:19, 20. Jun. 2008 (CEST)
- Ergänzung: die Sache wird für mich immer rätselhafter. Ich habe mal eine identische Arbeitskopie Benutzer:FordPrefect42/Europäische Union erstellt, um die Darstellung zu testen, aber in dieser Arbeitskopie taucht das Problem gar nicht auf! Kann es sein, dass das mit dem Seitenschutzstatus des Originalartikels Europäische Union zusammenhängt? Offenbar führt ja irgendein Syntaxfehler dazu, dass durch die Verschachtelung Artikel > Vorlage > Imagemap > Bild die Referenz auf die Bilddatei nicht korrekt aufgelöst werden kann. --FordPrefect42 13:23, 21. Jun. 2008 (CEST)
- Ich kann das Problem ebenfalls nicht nachvollziehen. Purge hilft nicht, ungesichtete Versionen gibt es auch nicht. Da kann nur jemand weiter helfen, der Einblick in die PHP-Quelltexte hat (Raymond?) --TM 14:17, 21. Jun. 2008 (CEST)
- PS: Es hat mit ziemlicher Sicherheits nichts mit der Vorlage zu tun sondern damit, dass der Artikel gesperrt ist. Alle anderen Einbindungen dieser Vorlage funktionieren fehlerfrei. --TM 14:30, 21. Jun. 2008 (CEST)
- Das stimmt so leider nicht. Vorlage:Imagemap Mitgliedstaaten der Europäischen Union/Test hat das gleiche Anzeigeproblem, und diese Testseite ist nicht gesperrt. Ich schlage vor, die Diskussion bei Vorlage Diskussion:Imagemap Mitgliedstaaten der Europäischen Union zu bündeln, denn es hat ziemlich sicher mit der Vorlage zu tun. PS: vielen Dank TMp, dass du dich der Sache annimmst. --FordPrefect42 14:37, 21. Jun. 2008 (CEST)
- Eigentlich ist es ganz einfach: Die Vorlage funktioniert für angemeldete Benutzer, also kann es nicht an der Vorlage liegen sondern es muss etwas mit der Anmeldung zu tun haben (Sichtungen, Sperren etc.). --TM 15:38, 21. Jun. 2008 (CEST)
- Das stimmt so leider nicht. Vorlage:Imagemap Mitgliedstaaten der Europäischen Union/Test hat das gleiche Anzeigeproblem, und diese Testseite ist nicht gesperrt. Ich schlage vor, die Diskussion bei Vorlage Diskussion:Imagemap Mitgliedstaaten der Europäischen Union zu bündeln, denn es hat ziemlich sicher mit der Vorlage zu tun. PS: vielen Dank TMp, dass du dich der Sache annimmst. --FordPrefect42 14:37, 21. Jun. 2008 (CEST)
- PS: Wenn ich abgemeldet auf die Seite Vorlage:Imagemap Mitgliedstaaten der Europäischen Union/Test gehe, sehe ich statt der zweiten Vorlageneinbindung die Fehlermeldung. Wenn ich die Seite bearbeite und ohne Änderung speichere, sehe ich plötzlich beide Vorlageneinbindungen. Wenn ich danach die Seite nochmal neu lade, ist aber wieder die Fehlermeldung da.
- Wenn ich unangemeldet eine Änderung vornehme, ist die Entwurfsfassung danach immer fehlerfrei, egal ob ich sie neu lade.
- Also für mich sieht das ziemlich sicher nach einem Softwareproblem mit den gesichteten Versionen aus. --TM 15:44, 21. Jun. 2008 (CEST)
- Gegenthese: die Testseite zeigt, dass nur Vorlageneinbindungen betroffen sind, bei denen der thumb-Parameter übergeben wird (soeben durch Umsortierung der Vorlageneinbindungen nochmal verifiziert, um auszuschließen, dass das Problem von dem Mehrfachaufruf herrührt). Das spricht für mich weiterhin sehr für ein Problem mit der Vorlage. Warum dieses Problem nur in Zusammenhang mit Nicht-Anmeldung auftaucht, und warum es weder bei der Vorschaufunktion noch beim Betrachten von Altversionen auftritt, ist eine zweite Frage. --FordPrefect42 16:03, 21. Jun. 2008 (CEST)
- PS: Dass dabei auch die gesichteten Versionen eine Rolle spielen, ist nicht zu bestreiten. Das erklärt, warum das Problem im Benutzernamensraum (wo es keine Sichtungen gibt) nicht auftaucht. --FordPrefect42 17:11, 21. Jun. 2008 (CEST)
- Entweder habe ich die totalen Tomaten auf den Augen oder ich sehe in keinem Fall eine Fehlermeldung. Das Sichterflag habe ich. --Revolus Echo der Stille 02:43, 22. Jun. 2008 (CEST)
- Den Fehler sieht man nur, wenn man nicht angemeldet ist. Hast du das ausprobiert? --FordPrefect42 03:12, 22. Jun. 2008 (CEST)
- Ich kann mich dem nur anschließen. Die stabile Version zeigt unangemeldet die Fehler, immer nur bei den Thumbs, aber wenn ich eine entwurfsansicht habe, sehe ich kein Fehlermeldung. Mal schauen. Der Umherirrende 22:48, 1. Jul. 2008 (CEST)
Anfragen
Hallo zusammen. Wo kann man Anfragen bezüglich erstellter Grafiken stellen (Fußballtrikots) [14]? -Lemmy- 22:26, 30. Jun. 2008 (CEST) PS:Ich weiß,dass es nicht hier her gehört,aber ich kann die richtige Seite partout nicht finden.Ich bitte um Entschuldigung.
- Am besten in der Grafikwerkstatt. --TM 21:33, 1. Jul. 2008 (CEST)
- Vielen Dank! -Lemmy- 21:33, 2. Jul. 2008 (CEST)
gallery-Baustein funktioniert immer?
Wollte <gallery>...</gallery> mit verschiedenen Parametern oder ohne Parameter auf Seite Maria-Valeria-Brücke anwenden. Leider gings nicht (einmal in der Endversion, dann nur noch in der Vorschau probiert). Auf dieser Seite ist kein <reverence> vorhanden, was irgendwo irgandwann mal in der Diskussion als möglicher Störenfried genannt wurde. Was also muß man noch beachten, was nicht unter Hilfe:Bilder erwähnt oder demonstriert wird, damits doch (immer) funktioniert? --Wikipit 19:18, 26. Aug. 2008 (CEST)
- Du darfst die Bilder innerhalb der gallery-Funktion nicht mit [[ ]] versehen. Dann klappt es. — Raymond Disk. Bew. 19:30, 26. Aug. 2008 (CEST)
- Danke! Aber nun ein neues Problem: Wie kann man verschiedene proportionierte Bilder in der Galerie in einheitlicher Höhe, dennoch in ausfüllender Breite (in einer Linie, in der Galerie) darstellen? Das Hochhausbeispiel zeigt dies nicht.--Wikipit
- Das wird denke ich nicht gehen, denn dafür müssten alle Bilder das gleiche Seitenformat und die gleiche Ausrichtung haben. Im Artikel sollen sowieso nur Vorschaubilder eingebunden werden. Wenn man am Bild näher interessiert ist, kann man sie sich nach einem weiteren Klick näher ansehen. -- defchris (Diskussion • Beiträge) 02:39, 5. Sep. 2008 (CEST)
- Vorschaubilder ja. Nur haben auch diese Proportionen wie die Originale. Ich fände es schöner, wenn in einer Galerie man die Höhe vereinheitlichen könne, derart, dass ein breiteres (Vorschau)Bild auch breiter dargstellt wird und ohne daß auch die anderen schmaleren (Vorschau)Bilder ebenfalls einen breitere unnützen Rahmen bekommen, also die Rahmen unnütz vereinheitlicht würden. Leider bekommt man ohne Gallery-Baustein Bilder nie in eine Reihe und die Postion ist obendrein noch von der Auflösung abhängig. Also wie kann es so optimal gehen?--Wikipit
- Mit Tabellen, „valign“ und dem upright-Parameter für thumbs kann man das hinbekommen. Das sollte aber Ausnahme bleiben, besser sind commons-Kategorien oder -Galerien, auf die verlinkt wird, um Artikel nicht mit Fotos zu überfrachten. -- Smial 19:42, 5. Sep. 2008 (CEST)
- Vorschaubilder ja. Nur haben auch diese Proportionen wie die Originale. Ich fände es schöner, wenn in einer Galerie man die Höhe vereinheitlichen könne, derart, dass ein breiteres (Vorschau)Bild auch breiter dargstellt wird und ohne daß auch die anderen schmaleren (Vorschau)Bilder ebenfalls einen breitere unnützen Rahmen bekommen, also die Rahmen unnütz vereinheitlicht würden. Leider bekommt man ohne Gallery-Baustein Bilder nie in eine Reihe und die Postion ist obendrein noch von der Auflösung abhängig. Also wie kann es so optimal gehen?--Wikipit
Bild Löschen
Könnte mir bitte jemand erklären wie man ein Bild wieder Löschd???--AGB 14:36, 5. Sep. 2008 (CEST)
- Löschen können nur Administratoren. Wenn du ein Bild unter eine frei Lizenz gestellt hast und es enzyklopädische Bedeutung hat, wird es gelöscht (es sei denn natürlich, ein besseres Bild zu diesem Thema steht zur verfügung). Wenn du dennoch meinst, dein Bild sollte gelöscht werden, kannst du es mit
{{löschen|Begründung --~~~~}}
markieren. Gruß, --RevoLus Echo der Stille 15:26, 5. Sep. 2008 (CEST)
galleries rechtsbündig?
kann mir jemand einen trick verraten, wie man gallerien rechtsbündig anlegt (so wie die meisten thumbs)?? danke!! --HilmarHansWerner 18:37, 22. Sep. 2008 (CEST)
- antwort schon gefunden: class="wikitable float-right" - stand zufällig hier drüber im code... --HilmarHansWerner 18:43, 22. Sep. 2008 (CEST)
uprightähnliches
Ich würde gern eine Serie von mehreren Bildern, welche keine gallery sein sollen, in der Höhe gleich machen, ohne mit beispielsweise x150px auf Höhe zu schrumpfen. Geht das? Conny 17:08, 16. Sep. 2008 (CEST).
- Was würdest du von einem "Riegel" halten. Gruß, --Revolus Echo der Stille 17:21, 16. Sep. 2008 (CEST)
Bild 1: Tarnung |
Bild 2: Tarnung |
Bild 3: Kopf Männchen |
Bild 4: Paarung |
Bild 5: vor dem Abflug |
- Der vertikale „Riegel“ sieht prinzipiell gut aus (hab’s etwas vereinfacht), trifft die Frage aber nicht. Die Frage hat sich auf die Höhe der Bilder bezogen. Der Anwendungsfall wird wahrscheinlich ein horizontaler „Riegel“ mit lauter gleich hohen Bildern sein. Dazu fällt mir aber nur
x150px
ein. --Fomafix 17:35, 16. Sep. 2008 (CEST)- Na ja, aber eigentlich soll man ja keine absoluten größenangaben benutzen. --Revolus Echo der Stille 17:38, 16. Sep. 2008 (CEST)
- Der vertikale „Riegel“ sieht prinzipiell gut aus (hab’s etwas vereinfacht), trifft die Frage aber nicht. Die Frage hat sich auf die Höhe der Bilder bezogen. Der Anwendungsfall wird wahrscheinlich ein horizontaler „Riegel“ mit lauter gleich hohen Bildern sein. Dazu fällt mir aber nur
-
Bild 1: Tarnung
-
Bild 2: Tarnung
-
Bild 3: Kopf Männchen
-
Bild 4: Paarung
-
Bild 5: vor dem Abflug
Ein vertikalen Riegel kann man übrigens auch mit gallery machen:
<gallery class="float-right" perrow="1"> Bild:Rosalia.alpina.bl01.jpg|Bild 1: Tarnung Bild:Rosalia.alpina.bl02.jpg|Bild 2: Tarnung Bild:Rosalia alpina detail.jpg|Bild 3: Kopf Männchen Bild:Rosalia.alpina.bl03.jpg|Bild 4: Paarung Bild:RosaliaAlpinaHu.jpg|Bild 5: vor dem Abflug </gallery>
gallery hat meines Wissens nach aber derzeit noch keine Möglichkeit der leserkonfigurierbaren Bildgrößen. --Fomafix 23:55, 23. Sep. 2008 (CEST)
upright und Laptops kompatibel
Wie sieht es aus bei den mit dem Upright-Tag im Zusammenhang mit Laptop-Anzeige, ist dies komaptibel oder gibt es Probleme. Wird ein Bild mit Uprightfaktor > 2 auf dem Laptopmonitor korrekt=identisch angezeigt wie auf normalen PC? -- JARU 21:35, 23. Sep. 2008 (CEST)
- Das mußt du den verwendeten Browser fragen. Upright=3 bedeutet bei Standardeinstellungen eine Bildbreite von 540 Pixeln. Das sollte auf laptops genauso 540px sein wie auf CRTs oder TFTs. -- Smial 23:34, 23. Sep. 2008 (CEST)
BILD vs. IMAGE
Auf der Hilfeseite wird die Einbindung von Bildern mittels [[Bild:...]] beschrieben. Ich habe das anfangs auch so gehandhabt, weil dies ja schließlich die deutschsprachige WP ist. Bei genauerer Betrachtung halte ich aber das ebenso funktionierende IMAGE für geeigneter, weil alle anderen Variablen (thumb, right, gallery...) der Syntax auch in englischer Sprache gehalten sind. Auch grenzt die englische Bezeichnung den Steuerbefehl deutlicher vom Artikeltext ab. Deshalb sollte man die Anleitung m.E. diesbzgl. ändern. --Hydro 22:13, 27. Okt. 2008 (CET)
- Nein, dann könnte man diese Seite auch Help Talk:Bilder nennen. --Revolus Echo der Stille 23:11, 27. Okt. 2008 (CET)
- Es geht mir nicht um den Namen dieser Seite, sondern den Text der Anleitung, der [[Bild:...]] statt [[IMAGE:...]] vorschreibt. --Hydro 23:20, 27. Okt. 2008 (CET)
- Ich bin dagegen, mehr englische Wörter im Quelltext zu verwenden als unbedingt notwendig. Wo die MediaWiki-Software aktuell nur englisch zulässt, können wir das vorerst nicht ändern. Aber wenn deutsche Wörter möglich sind, bin ich dafür, diese auch zu verwenden, um mögliche Hürden für Einsteiger und des Englischen nicht mächtige Mitarbeiter zu minimieren. -- Gruß, aka 12:26, 28. Okt. 2008 (CET)
- Mein Reden. Zwar weiß ich, was Image heißt, spanisch ist es Imagen ;) Aber wozu Barrieren aufbauen, wo bereits Lösungen existieren? Es gibt Leute, die kein englisch können. --RalfR → Berlin09 14:16, 28. Okt. 2008 (CET)
Imagemap und Tabellensortierung
Ohne | Mit |
---|---|
U1 | |
U55 |
Eine bescheidene Frage: Ist es möglich, dass man einzelne Spalten in Tabellen sortierfähig hinbekommt, auch wenn deren Inhalt nur aus Imagemaps besteht? Konkret geht's um solche Signets , , die anstelle des gleich lautenden Textes U1 bzw. U55 etc. stehen sollen. Ich hab's mal mit der kleinen Tabelle zu verdeutlichen versucht, die Spalte Mit lässt sich nicht mehr sortieren. Hier brauch ich ggf. Abhilfe. -- Platte U.N.V.E.U. 13:52, 28. Okt. 2008 (CET)
- Jetzt geht es. Details dazu gibt es hier: meta:Help:Sorting#Sorting_with_hidden_sortkey. -- Gruß, aka 14:07, 28. Okt. 2008 (CET)
- Wunderbar, wird nachher gleich mal umgesetzt. Danke. -- Platte U.N.V.E.U. 14:12, 28. Okt. 2008 (CET)
HDR-Bilder
Mir ist aufgefallen, dass immer häufiger normale Fotos gegen HDR-Aufnahmen ausgetauscht werden? Die sehen meißt sehr gut aus, aber ich frag mich ob das wirklich notwendig ist. Sollten nicht eher reale Fotos von Denkmälern, Landschaft usw. dargestellt werden als künstlerisch aussehende HDR-Aufnahmen?--halabalusa 14:48, 30. Nov. 2008 (CET)
- Ich lehne HDR-Fotos ab, die nach HDR aussehen, statt einen möglichst natürlichen Eindruck zu geben. Falls mittels HDR sehr schwierige Beleuchtungsbedingungen (Innenaufnahmen mit sonnenbeschienen Fenstern z.B.) gemeistert werden können, können die Bilder aber sinnvoll einsetzbar sein. Leider wird der Effekt oft um des Effektes willen völlig übertrieben eingesetzt. Ich für mein Teil würde in solchen Fällen einen Revert auf ein natürlicher wirkendes Foto befürworten, sofern die sonstige Bildqualität stimmt. -- Smial 17:01, 30. Nov. 2008 (CET)
Löschen von Teilen des Erklärungstextes
Hallo liebe Leute, ich finde diese beiden Teile informativ und brauche sie. Wenn das Ergebnis (z. B. Bilder in laufendem Text) auch anders zu erreichen ist dann kann da von mir aus auch gerne eine andere Erklärung rein. Aber die beiden Teile (Bilder im Fließtext ("inline") & Imagemaps als abweichende Vorschaubilder ) einfach ersatzlos zu löschen finde ich nicht ok. Und @Raymond: wenn die Bilder nicht lizenzkonform sind, dann gehören sie ausgetauscht und nicht der ganze Abschnitt hier weggelöscht! --Nati aus Sythen Diskussion 10:43, 2. Dez. 2008 (CET)
- Ich habe nur einen Teil (erneut) gelöscht, da die Anleitung zu einem Lizenzbruch auffordert. Es muss unbedingt ein Beispiel mit gemeinfreien Bildern gewählt werden, und ein Hinweis darauf auch in der Erklärung eingebaut werden. Bilder, die unter der GFDL/einer CC-Lizenz stehen, dürfen in der Form nicht verwendet werden, da man die Bildbeschreibungsseite und damit die Lizenzinformationen nicht mehr erreichen kann. Ich habe nur gerade nicht die Zeit, mir ein schöneres Beispiel auszudenken. Daher entschuldige bitte mein rigides Vorgehen, aber besser für den Moment keine Anleitung als eine Anleitung, die zum Lizenzbruch auffordert. — Raymond Disk. Bew. 10:59, 2. Dez. 2008 (CET)
- @Raymond: Hab ich die Lizenzproblematik so richtig formuliert? --Nati aus Sythen Diskussion 17:32, 2. Dez. 2008 (CET)
- Ich hatte dir bei Benutzer_Diskussion:Revolus#Hilfe:Bilder doch geantwortet. Ich war gestern bloß nicht online. Die Informationen in den beiden von mir gelöschten Absätzen sind schlichtweg veraltet, weshalb ich sie auch gelöscht habe. Man müsste anstatt derer eine Erklärung zu link einfügen. Ich habe die Hilfe nicht ordentlich genug gelesen, weshalb es mir nicht auffiel, dass das noch fehlt. Ich werde das später einfügen, wenn mir ein paar schöne Beispiele eingefallen sind. --Revolus Echo der Stille 13:19, 2. Dez. 2008 (CET)
- @Revolus: ich hab dir auch dort geantwortet. Außerdem denke ich die Erklärung zu link sollte halt zeitgleich mit dem Entfernen des veralteten Abschnittes geschehen. Es kann ja so viel dazwischen kommen und dann fehlt was ... . --Nati aus Sythen Diskussion 17:32, 2. Dez. 2008 (CET)
Inline-Bilder
Ich will Inline-Bilder aus Commons in eine Zeile einfügen (Es handelt sich um Zeichen aus Characters). Ich bekomme dann dauernd die Fehlermeldung: "<imagemap>-Fehler: Es muss mindestens ein Gebiet definiert werden". Was für ein Gebiet? Wo? Fingalo 16:31, 29. Nov. 2008 (CET)
- Hast du ein Beispiel, wo der Fehler aufgetreten ist? Welche Syntax verwendest du? — Raymond Disk. Bew. 23:30, 1. Dez. 2008 (CET)
Ich benutze die im Hauptartikel "unter "Bilder im Fließtext ("inline")" angegebene Syntax. Das Ergebnis siehst Du hier. Fingalo 09:29, 4. Dez. 2008 (CET)
Bild -> Datei
Ich habe die Änderung auf der Vorderseite rückgängig gemacht, wonach alle Einbindungen zukünftig durch Datei: vorgenommen werden sollten. Begründung: It's a wiki! Der Wiki-Code soll vor allem dazu dienen, gerade für Einsteiger leicht zu bedienen und zu verstehen zu sein. Es gibt keinen Grund, nur weil der Namensraum umbenannt wurde, nun alle Einbindungen umzuändern. IP 87 160 196 176 13:49, 12. Dez. 2008 (CET)
- Blubber: Die WMF hat uns die Namensräume verändert, dafür brauchen die keinen Konsens. sугсго 13:53, 12. Dez. 2008 (CET)
- Richtig, die Änderung des Namensraums ändert jedoch nichts an der Art der Einbindung. Und Bilder werden nunmal am einfachsten durch Bild: eingebunden. IP 87 160 196 176 13:56, 12. Dez. 2008 (CET)
- Und was ist ein Bild? Richtig, eine Datei! Und was ist eine "Media"? Richtig, eine Datei! Somit werden Dateien am einfachsten über den neuen Datei-Namensraum eingebunden. --STBR – !? 14:01, 12. Dez. 2008 (CET)
- Glaubst du wirklich, dass ein Neuling, der ein Bild einbinden möchte, sich erstmal überlegt, dass ein Bild ja eigentlich eine Datei ist? IMHO sollte in einem Wiki gelten: Sinnvoll ist, was am einfachsten und intuitivsten ist. IP 87 160 196 176 14:05, 12. Dez. 2008 (CET)
- Ein Neuling wird mit der Wikisyntax insgesamt am Anfang Probleme haben. Ob das nun Bild: oder Datei: heißt, ist bei Bildern also ziemlich egal, bei Audiodateien und Videos ist erstgenannte Variante nicht am intuitivsten und daher auch nicht sinnvoll. --A.Hellwig 14:07, 12. Dez. 2008 (CET)
- Richtig. Es spricht ja auch nichts dagegen, Audio- und Videodateien mit „Datei:“ einzubinden. Das Hauptproblem ist doch, dass eine solche Änderung an der Hilfeseite geradezu Leute dazu auffordert, loszurennen und Sinnlosedits zu machen, nur um die Einbindung zu ändern. (Siehe Benutzer Diskussion:S1#Bild -> Datei) IP 87 160 196 176 14:10, 12. Dez. 2008 (CET)
- Ich denke eben war es noch der Intuitivität wegen? Und ich habe auch noch keinen gesehen, der losgerannt ist, "Image" durch "Bild" zu ersetzen. --STBR – !? 14:13, 12. Dez. 2008 (CET)
- Ist ein Argument plötzlich schwächer, nur weil ein weiteres genannt wird?? Ein Beispiel fürs "Losrennen" habe ich doch oben bereits genannt, Spezial:Beiträge/S1 IP 87 160 196 176 14:16, 12. Dez. 2008 (CET)
- Wenn du selbst das neue Argument auf einmal als das Hauptproblem darstellst, schon. Und ein paar zentrale Infoboxen anzupassen, sehe ich nicht als losrennen. Und wie viele Benutzer hast du gesehen, die hier zuvor "herumgerannt" sind, um die Einbindung via "Image" durch "Bild" zu ersetzen? Ist doch nix anderes. --STBR – !? 14:21, 12. Dez. 2008 (CET)
- Mir ist nicht ganz klar, was das Eine mit dem Anderen zu tun hat. Die (recht seltenen) „Image:“ Einbindungen nebenbei durch „Bild:“ zu ersetzen, ist IMHO durchaus sinnvoll, da es die Lesbarkeit des Quelltextes verbesset. Aber sei's drum. Wenn die meisten Benutzer hier der Ansicht sind, dass „Datei:“ lesbarer und sinnvoller für die Einbindung eines Bildes ist als „Bild:“, soll es mir Recht sein. IP 87 160 196 176 14:33, 12. Dez. 2008 (CET)
- Wenn du selbst das neue Argument auf einmal als das Hauptproblem darstellst, schon. Und ein paar zentrale Infoboxen anzupassen, sehe ich nicht als losrennen. Und wie viele Benutzer hast du gesehen, die hier zuvor "herumgerannt" sind, um die Einbindung via "Image" durch "Bild" zu ersetzen? Ist doch nix anderes. --STBR – !? 14:21, 12. Dez. 2008 (CET)
- Ist ein Argument plötzlich schwächer, nur weil ein weiteres genannt wird?? Ein Beispiel fürs "Losrennen" habe ich doch oben bereits genannt, Spezial:Beiträge/S1 IP 87 160 196 176 14:16, 12. Dez. 2008 (CET)
- Ich denke eben war es noch der Intuitivität wegen? Und ich habe auch noch keinen gesehen, der losgerannt ist, "Image" durch "Bild" zu ersetzen. --STBR – !? 14:13, 12. Dez. 2008 (CET)
- Richtig. Es spricht ja auch nichts dagegen, Audio- und Videodateien mit „Datei:“ einzubinden. Das Hauptproblem ist doch, dass eine solche Änderung an der Hilfeseite geradezu Leute dazu auffordert, loszurennen und Sinnlosedits zu machen, nur um die Einbindung zu ändern. (Siehe Benutzer Diskussion:S1#Bild -> Datei) IP 87 160 196 176 14:10, 12. Dez. 2008 (CET)
- Ein Neuling wird mit der Wikisyntax insgesamt am Anfang Probleme haben. Ob das nun Bild: oder Datei: heißt, ist bei Bildern also ziemlich egal, bei Audiodateien und Videos ist erstgenannte Variante nicht am intuitivsten und daher auch nicht sinnvoll. --A.Hellwig 14:07, 12. Dez. 2008 (CET)
- Glaubst du wirklich, dass ein Neuling, der ein Bild einbinden möchte, sich erstmal überlegt, dass ein Bild ja eigentlich eine Datei ist? IMHO sollte in einem Wiki gelten: Sinnvoll ist, was am einfachsten und intuitivsten ist. IP 87 160 196 176 14:05, 12. Dez. 2008 (CET)
- Und was ist ein Bild? Richtig, eine Datei! Und was ist eine "Media"? Richtig, eine Datei! Somit werden Dateien am einfachsten über den neuen Datei-Namensraum eingebunden. --STBR – !? 14:01, 12. Dez. 2008 (CET)
- Richtig, die Änderung des Namensraums ändert jedoch nichts an der Art der Einbindung. Und Bilder werden nunmal am einfachsten durch Bild: eingebunden. IP 87 160 196 176 13:56, 12. Dez. 2008 (CET)
Imagemap in Vorlagen
Hallo, ich bin zu blöd um die Beschreibung zu verstehen - wie kann ich Imagemap in die Vorlage einbauen? Konkret gehts um Aulzhausen - die Lagekarte gehört in die Infobox rein, geht das? --Roterraecher !? 19:48, 10. Dez. 2008 (CET)
- Es geht, Gegenleistung: du tust die Vorlage:Imagemap Affing Dokumentieren und Kategorisieren. -- visi-on 15:18, 12. Dez. 2008 (CET)
- Danke! --Roterraecher !? 21:58, 13. Dez. 2008 (CET)
Das Attribut "frameless" tut nicht das, was man sich erwartet, wenn man sich den Abschnitt durchliest – jedenfalls nicht das, was ich mir dann erwarte: Es erscheint nämlich keine Bildunterschrift mehr, wenn "frameless" angegeben wird. Dazu zwei Fragen
- Warum wird die Unterschrift unterdrückt?
- Sofern dieses Verhalten wirklich gewünscht ist: Gibt es eine einfache Möglichkeit, Thumbnails ohne Rahmen aber mit Bildunterschrift zu erhalten? So wie es hier am Anfang gemacht wird ({| align="right" style="text-align:center"|[[Bild:Regelmaessiges_Siebeneck.jpg|200px|Darstellung eines regelmäßigen Siebenecks]]|-|Ein regelmäßiges Siebeneck|}) ist nicht gerade schön. --BerntieDisk. 18:44, 13. Dez. 2008 (CET)
- „frameless“ zeigt keine Bildunterschrift, weil es so programmiert ist. Es soll eben ein Analog zu „thumb“ mit Rahmen/Bildunterschrift sein, das genau wie „thumb“ automatisch nach den Benutzereinstellungen skaliert bzw. per „upright=“ frei skalierbar ist. Unter Bug 10587 enable caption for "border" and "frameless" mode wurde bereits der Wunsch nach einem „frameless“ mit Bildunterschrift geäußert. Eine einfach Möglichkeit kenne ich leider auch nicht. — Raymond Disk. Bew. 12:29, 14. Dez. 2008 (CET)
- "zeigt keine Bildunterschrift, weil es so programmiert ist" Das hab ich mir fast gedacht. ;-) Bleibt noch die Frage, warum es so programmiert wurde… Für das "Analog zu ‚thumb‘ mit Rahmen/Bildunterschrift" fehlt eben gerade die Unterschrift. Aber egal, ich hoffe einfach, dass der oben geäußerte Wunsch möglichst bald erfüllt wird. --BerntieDisk. 16:09, 14. Dez. 2008 (CET)
- Ok, missverständlich geschrieben. "Analog zu ‚thumb‘ mit Rahmen/Bildunterschrift" bezieht sich rückwärtig auf thumb. Ich habe frameless zwar programmiert, im Moment fehlt mir aber eine Idee, wie ich frameless mit Bildunterschrift realisieren kann. — Raymond Disk. Bew. 16:46, 14. Dez. 2008 (CET)
- Is schon gut. Wollte mich bloß erkundigen, was Sache ist. Es liegt mir fern, irgendwelche Ansprüche zu stellen. :-) --BerntieDisk. 17:12, 14. Dez. 2008 (CET)
Nicht Klickbares Bild
Hallo, gibt es die Möglichkeit, dass wenn ich ein Bild hochgeladen habe und es verlinkt habe im Text, also er zeigt es an, es zu unterbinden, dass man darauf klicken kann?
Ich möchte verhindern dass der Nutzer das Bild anklickt und sich somit fragt warum er nicht den Beitrag sieht, sondern irgendwas über ein Bild...
(Der vorstehende Beitrag stammt von 80.80.175.98 – 10:42, 3. Jul. 2008 (CEST) – und wurde nachträglich signiert.)
- Das geht, siehe Hilfe:Bilder#Imagemaps. Das sollte aber nur in begründeten Ausnahmefällen eingesetzt werden, z.B. um klickbare Karten zu erzeugen. Als generelle Lösung für normale Bilder im Text ist dies unerwünscht. — Raymond Disk. Bew. 11:07, 3. Jul. 2008 (CEST)
So, habe (glaube ich) das Plug-In richtig installiert. Wenn ich aber nun ein Image einbinden will mit <imagemap>Bild:Test.jpg</imagemap> dann steht da immer nur No Image oder ähnliches... Jemand eine Idee? Bei manchen sachen die ich gesehen habe schreiben die ja auch dass man <imagemap>image=Bild:Test.jpg</imagemap> schreiben muss... Stelle ich mich so blöd an?
Danke...
(Der vorstehende Beitrag stammt von 80.80.175.98 – 14:02, 3. Jul. 2008 (CEST) – und wurde nachträglich signiert.)
Halb umgezogene Dateien?
Habe bei Hilfe_Diskussion:Dateien_auf_Commons_verschieben#Halb_umgezogene_Dateien.3F bisher keine Antwort bekommen, aber ich denke hier ist auch ein guter Ort um die Frage zu platzieren. -- Avron 20:06, 29. Okt. 2008 (CET)
Bildlegenden auch unter vergrößerten Bildern?
Ich halte die Bildlegende für einen wichtigen Teil des Artikels. Die allererste Information können Bilder liefern. Zur weiteren Information genügen manchmal schon deren Legenden, bevor letzten Endes der Text zu lesen ist. Deshalb wäre es sinnvoll, unter der Vergrößerung eines Thumbnails die Legende zu wiederholen: eine m.E. lösbare Software-Aufgabe. --Analemma 13:00, 30. Okt. 2008 (CET)
Eigener Hint-Parameter wäre manchmal nützlich!
Wenn man mit der Maus über die Feder fährt wird der gleiche Hint (oder Tipp) eingeblendet ("Eine Feder mit Rahmen"), der schon unten angezeigt wird. Einen optionalen Parameter für zusätzliche Infos wie z.B. "Title=Vogelfeder zum Schreiben" fände ich gut! --Wikida 14:03, 13. Nov. 2008 (CET)
- 2009 -
Vorschaubilder
Hallo, ich wollte am Sonntag im Artikel Nymphenburger Park ein Bild im ersten Abschnitt mit Vorschau einbauen. Thumbnail funktioniert nicht mehr, wie man auch bei der Verbreitungskarte im Artikel Landkärtchen sehen kann ([[Bild:Araschnia lenava - Europa2.png|thumbnail=Araschnia lenava - Europa2-preview.png|thumb|Verbreitung des Landkärtchens in Europa]]). Was ist die Alternative? Verweis funktioniert nicht zusammen mit framed, das ist aber für die Bildunterschrift notwendig.
[[Datei:Schlosspark Nymphenburg-Vorschau.png|verweis=Schlosspark Nymphenburg.svg|framed|left|Übersichts-Skizze: ...]] linkt nur auf die Vorschau.
Gruß, --Grüner Flip 16:35, 13. Jan. 2009 (CET)
- Hallo,
verweis
funktioniert nicht zusammen mit Vorschaubildern. Schau dir dazu mal den entsprechenden Abschnitt noch mal an: Hilfe:Bilder#Von der Bildbeschreibungsseite abweichendes Linkziel. Gruß, --Revolus Apfel? 18:12, 13. Jan. 2009 (CET)- Danke, jetzt hae ich es verstanden. --Grüner Flip 17:48, 14. Jan. 2009 (CET)
wo kann man bilder hochladen?
Bitte, wo kann ich die Seite finden wo man Bilder auf Wikipedia tatsächlich (also praktisch gesprochen) hochladen kann (oder darf)??!! Eine solche Seite habe ich bisher nicht finden können, trotz es fast eine ganze Bibliotheke an "Bilder hochladen" Information gibt.... :-((((
--Blaricum 17:56, 17. Jan. 2009 (CET)
- Wenn Du angemeldet bist, dann gibt es auf jeder Seite i.d.R. links einen Link der "Hochladen" heißt. --Marsupilami (Disk|Beiträge) 20:01, 17. Jan. 2009 (CET)
Nochmals zu Klärung
Ich bin also gefordert bei der Artikelarbeit alle Bild: durch Datei: zu ersetzen und bei der Gelegenheit wären dann alle /thumb/ gleich durch /miniatur/ zuersetzen. Oder hat jemand die Idee ein Modul für den automatischen Lauf zum Umschreiben zu schaffen?? Oder werden für eine längere Zeit beide Versionen existieren „sollen“ „dürfen“. (nicht signierter Beitrag von Boonekamp (Diskussion | Beiträge) 20:55, 1. Feb. 2009)
- Diese Änderungen sollten nur gemacht werden, wenn auch weitere Änderungen an einem Artikel gemacht werden. Bearbeitungen, die ausschließlich diese Bezeichnungen änderen, erzeugen nur unnötige Artikelversionen. -- Smial 21:05, 1. Feb. 2009 (CET)
- Dem Vorredner kann ich mich nur anschließen. Außerdem bist du zu garnichts verpflichtet, kannst dies aber selbstverständlich nebenbei machen. Unter MediaWiki Diskussion:Gadgets-definition#neues Gadget: automatisches Übersetzen der Bilder-Syntax gibt es einen Vorschlag. Es werden aber auf jedenfall beide Versionen immer existieren, sie können auch beide verwendet werden, einen Unterschied im Ergebnis gibt es nicht. Die eine Variante könnte nur den Nicht-Englischsprechenden (Babel en-0) entgegenkommen. --Der Umherirrende 21:12, 1. Feb. 2009 (CET)
thumb
gudn tach!
warum soll "thumb" veraltet sein? -- seth 19:33, 13. Jan. 2009 (CET)
- Warum sollte es Bild sein, wenn man doch ein Bild einbindet und die Namen gleichbehandelt werden? Wobei jedoch nur File kanonisch ist. Thumbnail heißt auf deutsch nunmal Miniatur. Das Keyword ist jetzt übersetzt und das deutsche Wort sollte bevorzugt werden. --Revolus Apfel? 19:38, 13. Jan. 2009 (CET)
- "thumb" ist also nicht wirklich veraltet, sondern "miniatur" soll, weil's ein bissl deutscher sei (kommt ja eigentlich vom lateinischen uebers italienische zu uns), bevorzugt werden? dann sollte das auch so im hilfe-artikel stehen. momentan suggeriert der naemlich imho, dass "thumb" technisch veraltet sei. -- seth 19:55, 13. Jan. 2009 (CET)
- Ach, so meinst du das. Okay, etwas unglücklich ist es vielleicht wirklich formuliert. Fällt dir spontan etwas besseres ein? Gruß, --Revolus Apfel? 19:58, 13. Jan. 2009 (CET)
- Daumen!!!!einself -- Smial 20:24, 13. Jan. 2009 (CET)
- ich wuerde es so machen, wie im rest des artikels, d.h. die eingedeutschten begriffe fett und die universelleren, englischen nicht-fett, also so wie's weiter unten erklaert ist (z.b. in Hilfe:Bilder#Thumbnails). deshalb loeschte ich ja oben den redundanten und irrefuehrenden hinweis, der da oben eh keinem nutzt. ;-) -- seth 20:50, 13. Jan. 2009 (CET)
- Hm, da könntest du wohl Recht haben und
daumen
,richtig
undzentrum
wären wirklich interessantere Schlüsselwörter gewesen ;-) --Revolus Apfel? 21:00, 13. Jan. 2009 (CET)- Man könnte auch noch „Aufrecht“ und „mittig“ vorschlagen, ich hoffe nur inständigst, daß diese, äh, Scherze nicht zu sehr auf die Performance gehen... -- Smial 21:37, 13. Jan. 2009 (CET)
- Hm, da könntest du wohl Recht haben und
- Ach, so meinst du das. Okay, etwas unglücklich ist es vielleicht wirklich formuliert. Fällt dir spontan etwas besseres ein? Gruß, --Revolus Apfel? 19:58, 13. Jan. 2009 (CET)
- Hallo! Seth sagte: "deshalb loeschte ich ja oben den redundanten und irrefuehrenden hinweis, der da oben eh keinem nutzt."
- Ich denke, ich habe hier den "redundanten und irrefuehrenden hinweis" wieder eingefügt. Zur Begründung:
- Vor dem beanstandeten Satz steht: "Bilder werden normalerweise mit
[[Datei:Dateiname|miniatur|Beschreibung]]
eingebunden." Das ist die zentrale Information, die jeder Bilder-Neuling lesen sollte, sozusagen der Kern der ganzen Hilfe-Seite. Neu sind hier die Kennzeichen "Datei:" und "miniatur". Daher sollten beide im folgenden Satz genannt werden, damit es keine Verwirrung mit den älteren Standards gibt. - Ich bin übrigens vom Wechsel englisch-->deutsch ebenfalls nicht begeistert. Schönen Gruß --Emkaer 13:55, 15. Jan. 2009 (CET)
- hallo Emkaer, aber das steht doch alles weiter unten, hast du denn unsere diskussion nicht gelesen? "thumb" ist nicht veraltet. die leute, die bilder bereits mit "thumb" bilder eingebunden haben, duerfen das selbstverstaendlich weiterhin tun. der von dir wieder eingefugte satz laesst das aber unsinnigerweise als veraltet aussehen. falls sich jemand wundert, dass "thumb" jetzt nicht mehr oben steht, wird er sicher intelligent genug sein, noch ein paar saetze weiterzulesen. bitte revertiere deinen revert. -- seth 19:13, 17. Jan. 2009 (CET)
- related: WP:FZW#"miniatur" (permalink) -- seth 11:16, 18. Jan. 2009 (CET)
- Ich finde die Änderung kontraproduktiv. Wenn jede Wikipedia das so machen würde, kommt der Zeitpunkt, an dem man in einer anderen Sprachversion den Bildlink nicht mehr findet, weil man ihn vor lauter Lokalisierung nicht mehr erkennt. Seid so gut und ändert das zurück auf "thumb" – und zwar so schnell wie möglich, bevor sich das ausbreitet. --Matthiasb 17:04, 18. Jan. 2009 (CET)
- zumindest die "veraltet"-geschichte sollte damit erledigt sein und ich revertiere den kram nun selbst, da keine antwort mehr dagegen kam. fraglich bleibt nun, ob "miniatur" ueberhaupt verwendet werden sollte. ich sehe das aehnlich wie Matthiasb. die FZW-diskussion scheint irgendwie beendet zu sein. aber sicher bin ich mir da nicht. Revolus, magst du noch was dazu sagen (ausser "jehovah")? -- seth 23:01, 18. Jan. 2009 (CET)
- Technisch ist thumb natürlich nicht veraltet, genauso wenig wie Bild. Hast du _irgendeine_ Begründung, warum miniatur nicht verwendet werden sollte? Bis jetzt habe ich noch nicht eine einzige gehört. --Revolus Apfel? 23:11, 18. Jan. 2009 (CET)
- moment, der spiess wurde ja auf FZW mittlerweile umgedreht. die erste frage, die beantwortet werden sollte, ist "wo wurde 'thumb'->'miniatur' beschlossen?"
- eine begruendung gegen "miniatur" hat uebrigens Matthiasb geliefert. -- seth 00:09, 19. Jan. 2009 (CET)
- Sorry, dass ich nicht geantwortet habe; habe die Disk. aus den Augen verloren. Ich war davon ausgegangen, dass es irgend einen legitimen Beschluss gibt, den Kram "einzudeutschen". Das Argument von Matthiasb ist allerdings triftig. Daher würde mich die Begründung für die Änderung auch interessieren. --Emkaer 13:21, 21. Jan. 2009 (CET)
- Technisch ist thumb natürlich nicht veraltet, genauso wenig wie Bild. Hast du _irgendeine_ Begründung, warum miniatur nicht verwendet werden sollte? Bis jetzt habe ich noch nicht eine einzige gehört. --Revolus Apfel? 23:11, 18. Jan. 2009 (CET)
- zumindest die "veraltet"-geschichte sollte damit erledigt sein und ich revertiere den kram nun selbst, da keine antwort mehr dagegen kam. fraglich bleibt nun, ob "miniatur" ueberhaupt verwendet werden sollte. ich sehe das aehnlich wie Matthiasb. die FZW-diskussion scheint irgendwie beendet zu sein. aber sicher bin ich mir da nicht. Revolus, magst du noch was dazu sagen (ausser "jehovah")? -- seth 23:01, 18. Jan. 2009 (CET)
- Der „legitime Beschluss“, eine Lokalisierung vorzunehmen, besteht auf auf einer ganz anderen Ebene, nämlich der Weiterentwicklung von MediaWiki durch das Entwicklerteam (vor allem freiwillige Entwickler). MediaWiki wird nicht nur in den Projekten der Wikimedia Foundation eingesetzt, sondern auch von tausenden anderen Webseiten in allen nur denkbaren Sprachen. Daher wurde frühzeitig Wert auf eine möglichst umfassende Lokalisierbarkeit gelegt. Seit einiger Zeit sind auch alle Variablen und „magische Wörter“ lokalisierbar. Dies wurde, wir für viele anderen Sprachen, auch für die deutsche Sprache durchgeführt. — Raymond Disk. Bew. 14:11, 21. Jan. 2009 (CET)
- OK. Kann ich verstehen. Vielen Dank für die Erläuterung! Es ist auch eine gute Idee, dass auch "lokalisierte" Begriffe funktionieren. Die Frage ist: Wie gehen wir auf der Seite Hilfe:Bilder (und sonst in der de.wp) damit um? Was empfehlen wir?
- Meine Sorge ist, dass es Leute gibt, die die eine mögliche Benennung durch die andere ersetzen (nur im Quelltext sichtbar), und dass es außerdem Leute gibt, die das dann wiederum revertieren (weil sie mit der anderen Variante nicht klarzukommen meinen, sie unübersichtlich finden o.ä.), und dass es dann sogar zu Edit-Wars über "thumb" und "miniatur" kommen wird.
- Daher sollten wir uns hier jetzt ordentlich streiten, was besser ist (vgl. die Ansätze für Edit-Wars hier), uns dann auf einen Standard einigen, auf den man in künftigen Fällen verweisen kann. --Emkaer 14:24, 21. Jan. 2009 (CET)
- Ein Hinweis, das ein hin und her nicht gewünscht ist, scheint zwingend zu sein. Ich würde es so machen, wie es bei Hilfe:Tabelle umgesetzt ist. Erst wird das deutschsprachige genannt, danach das "alte" und ein Hinweis gibt es auch, das ein Hin und Her nicht erwünscht ist. Vielleicht kann man sich darauf einigen? Der Umherirrende 18:45, 21. Jan. 2009 (CET)
- Gern. Hauptsache, es wird nicht sinnbefreit hin-und-her-revertiert. -- Smial 18:53, 21. Jan. 2009 (CET)
- Ein Hinweis, das ein hin und her nicht gewünscht ist, scheint zwingend zu sein. Ich würde es so machen, wie es bei Hilfe:Tabelle umgesetzt ist. Erst wird das deutschsprachige genannt, danach das "alte" und ein Hinweis gibt es auch, das ein Hin und Her nicht erwünscht ist. Vielleicht kann man sich darauf einigen? Der Umherirrende 18:45, 21. Jan. 2009 (CET)
- Kann man so machen. Voraussetzung ist für mich, dass klar ist, ob die deutschsprachigen „magischen Wörter“ die empfohlene Variante darstellen, oder ob sie benutzt werden dürfen, aber nicht den optimalen Stand darstellen (wie man ja auch beliebige Formen der Literaturangabe verwenden darf, die aber alle noch bis zu den Vorgaben auf WP:LIT optimiert werden können). --Emkaer 19:19, 21. Jan. 2009 (CET)
miniatur was soll das denn sein: ein Adjektiv, ein Verb, ein falsch geschriebenes Substantiv? Mein XnView nennt das "lokalisiert" Miniaturansicht, was mir noch sprachlich nachvollziehbar erscheint. Gibts denn IT-Anwendungen außerhalb von de.wikipedia, die nach miniatur "lokalisieren"? ... Hafenbar 20:20, 21. Jan. 2009 (CET)
- in der jetzigen version werden bereits jeweils beide versionen miniatur und thumb angegeben in dem satz "Dazu fügt man den Zusatz miniatur oder thumb zwischen Dateiname und Alternativtext ein". das impliziert bereits, dass man beides verwenden kann und keines davon falsch ist. dadurch dass miniatur staerker hervogehoben wird, wird der lokalisierte begriff derzeit halt bloss etwas mehr gepusht.
- alternativ habe ich noch einen ganz anderen vorschlag: wenn wir thumb einfach lokalisiert als thumb belassen wuerden, weil thumbnail sowieso ein auch im deutschen verwendeter begriff ist, haetten wir diesbzgl. in zukunft keine technischen probleme, muessten uns nicht gedanken ueber eine (pseudo-)adaequate uebersetzung machen. -- seth 21:20, 21. Jan. 2009 (CET)
- (BK) Xfi nennt es "Icons", Ristretto "Miniaturbilder" und weitere Programme habe ich gerade nicht installiert. Miniatur (mit großem Initial) könnte man vielleicht auch zulassen, aber eigentlich sehe ich dafür keine Verwendung. "Vorschaubild" oder "Vorschau" wollte ich bei der Übersetzung nicht nehmen, weil es potentiel mit zu vielen existierenden Einbindungen und möglichen Einbindungen brechen würde. AUs diesem Grund ist die Kleinschreibung auch ein Vorteil. Gruß, --Revolus Apfel? 21:25, 21. Jan. 2009 (CET)
- Nochmal ganz von vorne bitte: ... Thumbnail heißt auf deutsch nunmal Miniatur ... --Revolus Apfel? 19:38, 13. Jan. 2009 (CET) ... woher stammt denn nun diese Weisheit? ... Hafenbar 13:09, 22. Jan. 2009 (CET)
- In der Tat, das ist großer Unfug ohne faktische Argumentationsbasis. Und selbst wenn das stimmen sollte (was es nicht tut), ist das überdies kein Argument gegen das in der deutschen Sprache nunmal wesentlich gebräuchlichere Lehnwort. Bitte diesen albernen Sprachpurismus rückgängig machen. --Asthma und Co. 01:10, 25. Jan. 2009 (CET)
- Aber sofort! Scheiss miniatur und hochkant! --dvdb 00:02, 15. Feb. 2009 (CET)
- In der Tat, das ist großer Unfug ohne faktische Argumentationsbasis. Und selbst wenn das stimmen sollte (was es nicht tut), ist das überdies kein Argument gegen das in der deutschen Sprache nunmal wesentlich gebräuchlichere Lehnwort. Bitte diesen albernen Sprachpurismus rückgängig machen. --Asthma und Co. 01:10, 25. Jan. 2009 (CET)
- Nochmal ganz von vorne bitte: ... Thumbnail heißt auf deutsch nunmal Miniatur ... --Revolus Apfel? 19:38, 13. Jan. 2009 (CET) ... woher stammt denn nun diese Weisheit? ... Hafenbar 13:09, 22. Jan. 2009 (CET)
Frage zum perrow der Galerien
Hallo. Man kann aber nur absolute Werte benutzen ja? Ich hätte lieber eine "auto"-Funktion gehabt aber das geht nicht oder? Also wäre nur für meine Benutzerseite, das eben so viele Bilder angezeigt werden, wie der jeweilige betrachtende Bildschirm des Nutzers hergibt. Ich hab alle in eine Zeile probiert und gehofft, er würde mir nen auto-Umbruch liefern... Hat aber nur einen horizontalen Scrollbalken erschaffen. Vllt. gibts ja doch nen Weg, Grüße --WissensDürster 11:18, 13. Feb. 2009 (CET)
- Ob das mit gallery geht, weiß ich nicht, aber als Workaround kann ich dir Benutzer:Smial/spielwiese anbieten, oben der erste Abschnitt. Funktioniert aber irgendwie nicht richtig mit thumbs. -- Smial 11:53, 13. Feb. 2009 (CET)
Ok danke. Also einfach mit div aneinander reihen, hätte mir auch einfällen können.^^ --WissensDürster 15:11, 13. Feb. 2009 (CET)
- Was macht denn Commons anders ? Wenn man auf Commons eine Galerie anlegt, verhält sie sich genau so, wie WissensDürster es oben beschreibt - sie passt sich an den Bildschirm an. Ich suche auch eine solche Funktion bei den Galerien. Der Befehl ist komischerweise bei Commons und Wikipedia der gleiche "<gallery> und </gallery>" aber das Verhalten ist unterschiedlich... Vielleicht lässt sich das ja vereinheitlichen - hin zur Commons-Version versteht sich ;-). Viele Grüße n8eule78 08:25, 25. Feb. 2009 (CET)
Durch Zufall bin ich wieder hier gelandet, habe es mir bei Commons angesehn und es stimmt. Genau solch eine Darstellung der "gallery" habe ich gesucht. Das muss doch ein system- und software-technisch begabter Administrator herausfinden können. Ich werde mal jemanden suchen ... Grüße --WissensDürster 14:07, 13. Mär. 2009 (CET)
- Auf Commons ist in Commons:MediaWiki:Monobook.js das Skript Commons:MediaWiki:ResizeGalleries.js eingebunden. Dieses sorgt für die Verteilung der Bilder per JavaScript. Ich habe das einmal testweise in meiner monobook.js eingebunden. Ob eine solche Funktion für den normalen Skin gewünscht ist müssten einmal diskutiert werden. Die Vorteile dieser Funktion liegen vermutlich auf der Hand. Die Funktion verschlechtert im Gegenzug aber die einheitliche Darstellung von Artikeln und führt zu weiterem JavaScript im normalen Skin. Eine Einführung als Gadget kann ich mir gut vorstellen. Liebe Grüße --M.L 15:34, 13. Mär. 2009 (CET)
Ok Diskussion wird auf http://de.wikipedia.org/wiki/Wikipedia:Verbesserungsvorschl%C3%A4ge#GalerieSize_als_JavaScript_oder_Gadget weitergeführt. --WissensDürster 16:12, 13. Mär. 2009 (CET)
Prinzipielles zur Anordnung
Hallo. Habe ich das richtig verstanden, dass man z. B. nicht auf einzelne Bildschirm-Auflösungen achten muss? Bilder in die Abschnitte zu packen und nicht direkt überlappen zu lassen etc. mache ich natürlich, aber ich habe z. B. den Artikel Frühlings-Adonisröschen bearbeitet und das thumb-Bild liegt in 1024 noch in "Beschreibung"; auf einem Widescreen-Bildschirm aber wird der folgende Abschnitt dadurch verschoben. Das ist also nicht so wichtig ja? Grüße --WissensDürster 14:26, 12. Mär. 2009 (CET)
- Richtig, auf die Darstellung in einzelnen Browsern kann man nicht achten, da gibt es zu viele Unterschiede. Wichtiger ist es, möglichst keine festen Bildgrößen zu verwenden, um angemeldeten Benutzern die Bildern in ihrer Wunschgröße anzeigen zu lassen. --Martin Zeise ✉ 22:15, 12. Mär. 2009 (CET)
Ok. Vielen Dank für die rasche Antwort auf diese triviale Frage. Grüße --WissensDürster 14:04, 13. Mär. 2009 (CET)
Breite bzw. Größe (von thumb) erzwingen?
Hallo. Ich habe ein kleines gif in Wikipedia:Verhalten gegenüber Neulingen eingefügt. Das muss auch nicht größer sein und ist ganz schick. Aber der Text verschwindet leicht in der Beschreibung, kann ich von dem Thumb die Größe beeinflussen? Also das gif hat schon maximal Größe und ich will nur das mehr Platz für den Text bleibt. Danke --WissensDürster 12:44, 24. Mär. 2009 (CET)
- upright/hochkant heist das Zauberwort →Hilfe:Bilder-- visi-on 12:56, 24. Mär. 2009 (CET)
Tut mir leid, ich versteh's einfach net.
Das alles:
[[Datei:Movicon-nihao.gif|100px|thumb|[[Wikipedia:Begrüßung|Willkommen]] Neulinge]]
[[Datei:Movicon-nihao.gif|upright|thumb|[[Wikipedia:Begrüßung|Willkommen]] Neulinge]]
[[Datei:Movicon-nihao.gif|upright|miniatur|[[Wikipedia:Begrüßung|Willkommen]] Neulinge]]
bringt immer dasselbe falsche Ergebnis. Was muss ich daran ändern? --WissensDürster 13:14, 24. Mär. 2009 (CET)
- Da kannst du nichts machen. Zusammen mit thumb oder frameless werden die Bilder nie über ihre eigentliche Größe hinweg vergrößert. Du könntest das Bild mit The GIMP vergrößert hochladen. Gruß, --Revolus Echo der Stille 15:17, 24. Mär. 2009 (CET)
Nein will ich ja gar nicht, das Bild ist perfekt so, ich will nur die "thumb-vorlage" mit "innen-padding"(?) vergrößern, das das Bild so bleibt, aber der Text im thumb besser aussieht, das meinte ich. Kann man da was machen? --WissensDürster 16:00, 24. Mär. 2009 (CET)
- Kannst du: [15]. Ich hab den von Mediawiki generierten HTML-Code genommen und die feste Breite entfernt. Gruß, --Revolus Echo der Stille 16:33, 24. Mär. 2009 (CET)
Ok danke, genau sowas hab ich gesucht =) Nun werden sich alle Neulinge gleich doppelt freun ;) --WissensDürster 17:03, 24. Mär. 2009 (CET)
Namensraum-Vorlage?
Was macht diese Namensraum-Vorlage in der Bilder-Hilfe? Es gibt keinen Bildernamensraum... aso weil's allg. um Medien-Daten geht? Trotzdem verwirrend, wieso wechselt das immer zwischen Hilfe: und Wikipedia: Namensraum xD und wieso gibts die Vorlage nicht unter Hilfe:Datein wo sie ja auch hinführt... PS: Gab es nicht sowas wie eine "Bilder-Werkstatt", das suche ich gerade. Danke --WissensDürster 17:50, 28. Mär. 2009 (CET)
- ich weiß nicht, was du mit Namensraum-Vorlage meinst, die Trennung der Namensräume ist aber schwierig. Die Bilderwerkstatt findet sich unter WP:Bilderwerkstatt --17:57, 28. Mär. 2009 (CET)
Gemeint ist das. Nun ist es auch unten auf der Bilder-Hilfe. Aber egal, danke für den Link, das hab ich gesucht =) --WissensDürster 18:00, 28. Mär. 2009 (CET)
- Aso, die Navigationsleiste meintest du, dort ist es genauso schwierig die passenden Informationen zuhalten. Mal schauen, ob man da noch was machen kann. Der Umherirrende 18:05, 28. Mär. 2009 (CET)
Bildanzeige
Das Bild ist zwar da, wird aber nicht im Miniatur-format angezeigt?? Kann mir jemand evtl. bitte das Problem erklären? --Störfix 20:44, 13. Apr. 2009 (CEST)
- Also bei mir wird das Bild nicht nur nicht als Vorschau (miniatur), sondern auch nicht auf der Seite Datei:Hbf-Erfurt2.png angezeigt. Hier hingegen schon. Und hier auf Commons ist es auch nicht zu sehen. Faszinierend.
- Ich könnte mir vorstellen, dass durch die Änderung des Bildes ein Element in die Datei geraten, ist, das Probleme bereitet. Vielleicht würde es helfen, eine Version mit wieder etwas höherer Auflösung zu erstellen. Größere Bilder schaden ja nicht. --Emkaer 21:04, 13. Apr. 2009 (CEST)
- Interlace rausgenommen. Soll jetzt das gleichnamige Bild auf commons damit überschrieben werden? -- smial disk 21:55, 13. Apr. 2009 (CEST)
- Danke! 1) Ja 2) Wie kann ich einen interlace rausnehmen?? --Störfix 22:16, 13. Apr. 2009 (CEST)
- Interlace ist bei Bildern ein Verfahren, daß die Bilder bei der Darstellung zeilenversetzt aufbaut, im einfachsten Fall werden erst alle ungeraden, dann alle geraden Zeilen gemalt. Das Bild ist dadurch beim Laden schneller am Bildschirm sichtbar, wenn auch zunächst in verringerter Auflösung. Du müßtest in der von Dir verwendeten Software in den Optionen einmal nachschauen, ob es dort ein Häkchen gibt, um dieses Speicherformat auszuschalten, der Mediawiki-Konverter kommt anscheinend nicht damit zurecht. Ich habe das Bild in Irfanview geladen und gleich wieder abgespeichert, in den Standardeinstellungen macht der kein Interlace. Ehrlich gesagt wußte ich bis heute nicht, daß PNG das auch unterstützt, ich kannte das bisher nur bei GIF. -- smial disk 23:30, 13. Apr. 2009 (CEST)
- Danke! 1) Ja 2) Wie kann ich einen interlace rausnehmen?? --Störfix 22:16, 13. Apr. 2009 (CEST)
"File:" oder "Datei:"?
Hallo! Folgendes: Ein weiser Wiki-Kollege meinte zu mir, ich solle Bilddateien vornehmlich per "Datei:" statt "File:" einfügen. Macht das überhaupt einen Unterschied? Ich habe alle meine Bilddateien auf die Wiki Commons geladen und verwende stets "File:", da ich das dann so gleich auch in anderssprachigen Wiki-Versionen verwenden kann.
Warum sollte ich nur "Datei:" verwenden? Gibt es da handfeste Gründe, die gegen "File:" zum Einbinden von Bildern sprechen?
Gute Nacht & Grüße, Horst-schlaemma 00:10, 10. Apr. 2009 (CEST)
- gudn tach!
- es gibt keine technischen gruende, "datei" zu bevorzugen. und es gibt geteilte auffassungen darueber, welcher der beiden begriffe in der deutschsprachigen wikipedia verwendet werden soll. eine mehrheit (zu der ich nicht zaehle) ist wohl fuer "datei", dennoch darfst du auch gerne "file" schreiben. -- seth 00:16, 10. Apr. 2009 (CEST)
- Verstehe. Was spricht denn dafür, "Datei" zu verwenden? In meinen Augen macht dessen Verwendung gar keinen Sinn, da "File" ja im Prinzip überall kompatibel ist und auch nicht grad einen übermäßig komplizierten Befehl darstellt ;) Geht es dabei nur um den Kampf wider Anglizismen oder hat das noch andere Hintergründe? -- Horst-schlaemma 01:31, 10. Apr. 2009 (CEST)
Kann mir sonst noch jemand etwas dazu sagen? Vielleicht aus der "Datei"-Fraktion? ;) Gruß, Horst-schlaemma 11:07, 10. Apr. 2009 (CEST)
- Es bleibt dir vollkommen selbst überlassen. Ich zB finde Bild passender für Bilder … aus naheliegenden Gründen; aber ich würde das nie zu Datei, File oder Image ändern. Generell gilt: Wenn die dt. Bezeichnung drin ist, drin lassen, wenn eine andere drin ist, darfst du sie ändern, bloß sollte das nicht die einzige Änderung deines Edits sein. Gruß, --Revolus Echo der Stille 11:17, 10. Apr. 2009 (CEST)
- Grund für landessprachliche Bezeichnungen ist wohl auch, die Lesbarkeit und Weiterverwendung des Quelltextes für Nutzer ohne oder mit geringen Fremdsprachenkenntnissen zu erhöhen. --Niteshift 11:19, 10. Apr. 2009 (CEST)
- Wobei man bei dem Wort "File" (as zigfach überall im Netz in Verwenbdung ist und bei uns z.B. auf Commons dem Großteil unser Medien vorsteht) schon viel Phanatsie braucht um eine Sprachbarriere herbeizureden. Ich weiß, es gibt User ohne Englischkenntnisse, die z.B. mit englischen Metaankündigungen nichts anfangen können, aber mit "image" oder jetzt "file" habe ich selbst bei ihnen noch nie eine Barriere erlebt. Gruß Julius1990 Disk. 11:27, 10. Apr. 2009 (CEST) PS: Aber soll jeder seine Meinung haben, ich will da über Ostern nicht streiten. Ich für meinen Teil werde weiterhin überzeugt "File" verwenden. Julius1990 Disk. 11:31, 10. Apr. 2009 (CEST)
Also herrscht Übereinkunft, dass beide Varianten möglich sind, ja? Aber wäre "File" ob der besseren Kompatibilität, intl. Verständlichkeit etc. dann nicht zu bevorzugen? Könnten nicht alle "Dateien" & "Bilder" in "Files" transferiert werden, um das Bezeichnungschaos zu beenden und die Server zu entlasten? MMn wäre das schon sinnvoll. Grüße, Horst-schlaemma 18:29, 14. Apr. 2009 (CEST)
- Keine Sorge, dass dein Benutzername dasteht ist hundertmal so aufwendig wie die Synonyme. Gruß, --Revolus Echo der Stille 19:10, 14. Apr. 2009 (CEST)
Dateien in Infoboxen
Die Einbindung von Dateien in Infoboxen bereitet mir Schwierigkeiten, da die Datei entweder gar nicht angezeigt wird oder mit Text, der eigentlich nur im Quelltext zu sehen sein sollte. Wer weiß Rat? --Verwaltungsgliederung 14:00, 18. Apr. 2009 (CEST)
- Bitte erläutere das genauer. Meinst Du auch Bilder in Infoboxen (so wie hier?). Oder geht es um einen konkreten Fall? Hast Du Dir mal verschiedene eingebundene Infoboxen angeschaut? Gruß --Emkaer 14:10, 18. Apr. 2009 (CEST)
- Ich schätze es geht um die Vorlage:Infobox Litauischer Landkreis. Da einfach nur den Dateinamen eintragen. Ohne Bild: oder sonstiges Drumherum. --Revolus Echo der Stille 17:47, 18. Apr. 2009 (CEST)
Hochladen?
Ich beiße mir an der Hochladen-Funktion schon seit einiger Zeit die Zähne aus. Andauernd kommt da eine Nachricht wie:
Die Datei ist beschädigt oder hat einen falschen Namen. Bitte überprüfen Sie die Datei und laden Sie sie erneut hoch.
Was mache ich nur falsch?? Auf dem Computer kann die Datei problemlos angezeigt werden, und auch an der Dateiendung (jpg/gif/... habe schon alles versucht) kann es nicht liegen. Egal was ich mache - es klappt einfach nicht. --Gipsbein 1 18:28, 21. Apr. 2009 (CEST)
- Ist das die erste Datei, die du versuchst hochzuladen? Wenn ja, probier's erstmal mit einer anderen, ob das anstandslos funktioniert. Wenn ja, speicher die erste Datei in einem Bildbearbeitungsprogramm testhalber mal in einem anderen Format (z.b. PNG) und mit neuem Namen und probier's damit nochmal. Es kann schon passieren, dass eine Datei lokal gut angezeigt wird, MediaWiki sie aber - zu recht oder unrecht - fuer beschaedigt haelt. --Elian Φ 02:58, 22. Apr. 2009 (CEST)
- Ist nicht die erste Datei, bei der ich es verscuhe - gelungen ist es mir noch nie.--Gipsbein 1 23:19, 22. Apr. 2009 (CEST)
- Hast Du das Hochladen auf Commons schon probiert? Die dort hochgeladenen Bilder kannst Du auch in der deutschsprachigen Wikipedia einbinden. -- 3268zauber 23:22, 22. Apr. 2009 (CEST)
- Habe schon alles mögliche probiert - auf Commons geht es auch nicht. Ich bekomme kein einziges Bild hoch, egal, wie es heißt! --Gipsbein 1 23:23, 22. Apr. 2009 (CEST)
- Bist Du mit dem Tipp von Elian weitergekommen? Falls nein: Du kennst sicher diese Seite? Hier wird nochmals Schritt für Schritt erklärt, wie man Bilder hier hochlädt. -- 3268zauber 23:40, 22. Apr. 2009 (CEST)
- Die Seite kenne ich - es geht aber trotzdem nicht.--Gipsbein 1 21:26, 24. Apr. 2009 (CEST)
- Hallo Gipsbein, ich kenne das, einfach zum aus der Haut fahren. Bevor das passiert, doch noch ein Tipp: stelle Deine Frage doch noch einmal hier, am besten mit einem konkreten Beispiel, wie Du vorgegangen bist. Viele erfahrene Wikipedianer haben diese Seite auf ihrem Schirm, da kann Dir sicher jemand helfen! Gruß, -- 3268zauber 22:06, 24. Apr. 2009 (CEST)
- Die Seite kenne ich - es geht aber trotzdem nicht.--Gipsbein 1 21:26, 24. Apr. 2009 (CEST)
- Bist Du mit dem Tipp von Elian weitergekommen? Falls nein: Du kennst sicher diese Seite? Hier wird nochmals Schritt für Schritt erklärt, wie man Bilder hier hochlädt. -- 3268zauber 23:40, 22. Apr. 2009 (CEST)
- Habe schon alles mögliche probiert - auf Commons geht es auch nicht. Ich bekomme kein einziges Bild hoch, egal, wie es heißt! --Gipsbein 1 23:23, 22. Apr. 2009 (CEST)
- Hast Du das Hochladen auf Commons schon probiert? Die dort hochgeladenen Bilder kannst Du auch in der deutschsprachigen Wikipedia einbinden. -- 3268zauber 23:22, 22. Apr. 2009 (CEST)
- Ist nicht die erste Datei, bei der ich es verscuhe - gelungen ist es mir noch nie.--Gipsbein 1 23:19, 22. Apr. 2009 (CEST)
Was zuerst?
Muss man im Quelltext erst gerahmt und dann miniatur|150px oder erst miniatur|150px und dann gerahmt angeben? In beiden Fällen (s. Chattahoochee-Oconee National Forest#Heute) bekommt meine Datei zwar ein Rahmen, bleib aber in der Originalgröße. Was habe ich falsch gemacht? --Verwaltungsgliederung 12:26, 25. Apr. 2009 (CEST)
- Thumbnails haben automatisch einen Rahmen, steht auch umseitig. Ich habe das Bild jetzt mal verkleinert, die jetzige Darstellung gefällt mir aber auch nicht (Karte schlecht zu lesen). Das weitere Vorgehen überlasse ich trotzdem dir. Viele Grüße --Isderion 16:34, 25. Apr. 2009 (CEST)
Also von der Schrift her kann man das schon gut lesen. Außerdem denke ich mal, dass jemand, der sich für die Karte interessiert, sie schon anklicken wird. In der vergrößerten Ansicht kann man m. M. n. die Schrift schon gut lesen. -- Verwaltungsgliederung 17:45, 27. Apr. 2009 (CEST)
Eine konkrete Bitte
Wer kann uns das Portal:Body Modification so einrichten dass der Text die Bilder mit einem kleinen Puffer umflisst. Besonders auffällig ist es beim derzeitigen Artikel des Monats. Dort kleben die Buchstaben buchstäblich am Foto * --Nicor 01:48, 3. Jun. 2009 (CEST)
* finde das Wortspiel!
- Problem solved.--Lamilli 19:22, 6. Jun. 2009 (CEST)
Skalierung von querformatigen Bildern?
Hallo? Es wird ja gewünscht, Bilder nicht absolut in Pixel zu skalieren, sondern relativ als thumb und mit upright - und das unterstütze ich auch sehr. Upright soll man für hochformatige Bilder verwenden. Bei dieser Angabe kann man auch einen Wert zur Skalierung angeben, bspw. upright=2.5. Was ist aber, wenn ich ein querformatiges Bild skalieren will, bspw, weil der Text darauf sonst nicht lesbar ist? Soll ich da upright "zweckentfremden" oder gibt es auch einen Skalierwert für querformatige Bilder? Danke & lG --menphrad✉ 10:29, 24. Jun. 2009 (CEST)
- Ich mach das so, ich nutze "Hochkant=x.x" auch für querformatige Bilder. Allerdings nehm ich die deutsche Bezeichnungen, also miniatur, hockant, Datei, ... Weitere Infos zu Bilderformatierungen gibt es übrigens auf Hilfe:Bilder (falls du es noch nicht kennst). --Nati aus Sythen Diskussion 10:54, 24. Jun. 2009 (CEST)
- Von dort komme ich ja, nur unter Hilfe:Bilder#Hoch- und querformatige Bilder kombinieren – automatische Skalierung steht ja leider nicht mehr als das, was ich geschildert habe. Daher habe ich, so wie Du, upright zweckentfremdet. Generell finde ich es ein wenig merkwürdig, dass all die Angaben auch germanisiert werden - in HTML gibt es ja auch keine deutschen Properties!? --menphrad✉ 11:39, 24. Jun. 2009 (CEST)
- Ich hatte „upright“ speziell für Hochformatbilder programmiert. Mit „upright=x.x“ kann man aber jedes beliebige Bild relativ größer oder kleiner machen. Also z.B. Panoramafotos, die ja deutlich breiter als hoch sind, mit „upright=2.5“ ansehnlich in einen Artikel einbauen. — Raymond Disk. Bew. 21:55, 24. Jun. 2009 (CEST)
- Von dort komme ich ja, nur unter Hilfe:Bilder#Hoch- und querformatige Bilder kombinieren – automatische Skalierung steht ja leider nicht mehr als das, was ich geschildert habe. Daher habe ich, so wie Du, upright zweckentfremdet. Generell finde ich es ein wenig merkwürdig, dass all die Angaben auch germanisiert werden - in HTML gibt es ja auch keine deutschen Properties!? --menphrad✉ 11:39, 24. Jun. 2009 (CEST)
mehrere Galerien?
Hallo zusammen! Ich habe auf meiner persönlichen Seite zwei Galerien angelegt. Leider werden sie nicht untereinander sondern nebeneinander angezeigt (FF 3.0.x / Linux) und stehen nicht unter den passenden Überschriften. Wie muss ich die Galerien formatieren, damit das ordentlich aussieht? Danke und Gruss -- GrößterZwergDerWelt 21:53, 30. Jun. 2009 (CEST)
- Du muss
align=right
entfernen. --Fomafix 22:09, 30. Jun. 2009 (CEST) - . Danke! Gruss -- GrößterZwergDerWelt 23:52, 30. Jun. 2009 (CEST)
Skalierung aufgrund der Bedeutung?
Ich habe heute einen Diskussionseintrag verfasst, bei dem ich vorschlage, die Bilder aufgrund ihrer nicht so hohen Relevanz für den Artikel nicht in Standardgröße darzustellen sondern etwas kleiner. Spricht etwas dagegen einen entsprechenden Hinweis in diesen Hilfe-Artikel hier aufzunehmen? Der Parameter upright
sollte sich gemäß obigen Diskussionsbeitrag problemlos dafür verwenden lassen (siehe insbesondere Beitrag von Raymond an 4. Stelle). --Fit 20:58, 2. Jul. 2009 (CEST)
- Technisch hast du Recht, inhaltlich auf den genannten Artikel würde ich erstmal nicht widersprechen wollen ;-) Aber als grundsätzliche Anleitung/Regel würde ich es ungerne in diese Hilfe aufnehmen wollen. Dafür sind die Anwendungsfälle zu unterschiedlich und ich sehe schon die Regelhuber, die sich dann bei allen möglichen Artikeln auf genau diese Regel beziehen würden. — Raymond Disk. Bew. 22:20, 2. Jul. 2009 (CEST)
- Ja, wenn überhaupt, dann sollte man es als technische Möglichkeit zur inhaltlichen Gewichtung mit einem guten Beispiel, das ich zur Zeit noch nicht parat habe, in die Hilfe aufnehmen, aber nicht als Regel. Den Regelhubern kommt man ohnehin am besten bei, indem man die Regeln, besser Hinweise, möglichst offen und stufenlos schreibt. Ich sehe die Möglichkeit zur Gewichtung der Bilder durch Größenveränderung auch einen Weg zur Verbesserung von Artikeln. --Fit 23:57, 2. Jul. 2009 (CEST)
- Die Standardgröße mit 180px ist ein ganz ausgezeichneter, bewährter Kompromiß, der durch den upright-Parameter (ohne Größenangabe) sinnvoll ergänzt wurde, um hochformatige Bilder nicht unproportional riesig erscheinen zu lassen. Ich halte es für völlig überflüssig, eine Empfehlung für irgendwelche Skalierungen nach "Wichtigkeit" festzuschreiben, die Bilder in dieser Artikelversion halte ich btw. für viel zu klein. -- smial disk 01:08, 3. Jul. 2009 (CEST)
- Mittlerweile hatte ich auch schon gemerkt, daß ich als Standardwert 300px eingestellt hatte und damit natürlich einen anderen Artikel zu sehen bekomme, als die Leute mit Standardwerten. --Fit 01:26, 3. Jul. 2009 (CEST)
- Deshalb arbeite ich stets mit der Standardeinstellung, die meisten Leser der WP dürften nicht angemeldet sein und daher genau das vorgesetzt bekommen. Dafür muß es vornehmlich „passen“ meiner Meinung nach. Wobei man durchaus darüber nachdenken könnte, diesen 180px-Standard in der Zukunft mal etwas zu vergrößern, da ja auch zunehmend Bildschirme mit höheren Auflösungen als 1024*768 eingesetzt werden, bei einem 1920*sowieso Widescreen-Monitor erscheinen die doch schon recht klein; auch Notebooks haben heute ja schon oft 1440*xxx oder mehr. -- smial disk 02:03, 3. Jul. 2009 (CEST) (Wirklich geil wäre eine (prozentuale) Skalierung nach aktueller Browserfensterbreite, aber das dürfte die Server wegen der ständig erforderlichen Neuberechnung bei jedem Artikelaufruf an den Rand des Wahnsinns treiben....)
- Mittlerweile hatte ich auch schon gemerkt, daß ich als Standardwert 300px eingestellt hatte und damit natürlich einen anderen Artikel zu sehen bekomme, als die Leute mit Standardwerten. --Fit 01:26, 3. Jul. 2009 (CEST)
Wie wird die Skalierung technisch eigentlich umgesetzt? Werden die Thumbnails jedes mal neu berechnet? --Fit 01:26, 3. Jul. 2009 (CEST)
- Nur bei Änderungen, danach kommen die fertig skaliert aus dem Cache. Es wird auch nicht stufenlos skaliert - upright=0.55 und upright= 0.56 kann durchaus genau dieselbe Bildgröße ergeben. -- smial disk 02:03, 3. Jul. 2009 (CEST)
- ausserdem macht die fensterabhängige dynamische bildgrössenskalierung die nächste browsergeneration, um die brauchen wir uns sowieso nicht kümmern - wir müssen nur WCAG-tauglichen sourcecode und ein anständiges CSS anbieten, dann geht alles am besten --W!B: 01:43, 4. Jul. 2009 (CEST)
- Wie funktioniert das? Die Browser ziehen sich stets die volle Bildgröße und skalieren dann? Das gäbe aber Traffic... -- smial disk 01:52, 4. Jul. 2009 (CEST)
- ausserdem macht die fensterabhängige dynamische bildgrössenskalierung die nächste browsergeneration, um die brauchen wir uns sowieso nicht kümmern - wir müssen nur WCAG-tauglichen sourcecode und ein anständiges CSS anbieten, dann geht alles am besten --W!B: 01:43, 4. Jul. 2009 (CEST)
Problem mit SVG-Bildern im Miniatur-Format
Gewisse SVG-Dateien werden im Zusammenhang mit dem miniatur
-Parameter nicht richtig ausgegeben und erscheinen zu schmal (siehe Beispielsgraphiken rechts, untere Graphik). Aus welchem Grund werden sie zu schmal angezeigt und was kann man dagegen tun? Handelt es sich eventuell sogar um einen Bug in der MediaWiki-Software? Liebe Grüße, Debianux 09:08, 10. Jun. 2009 (CEST)
- Habe die Elemente der SVG-Datei in eine neue Datei kopiert und unter anderem eine viewBox-Zeile ergänzt. Viele Grüße --Marsupilami (Disk|Beiträge) 18:38, 19. Jun. 2009 (CEST)
- Danke. Darf ich fragen, was eine ›viewBox‹ genau ist? Ich verwende SVG-Graphiken praktisch ausschließlich mit Inkscape und bin deswegen mit dem Quelltext nicht so vertraut. Könnte man deine Änderung per Bot bei allen Dateien in den folgenden Kategorien durchführen? Das Skalierungs-Problem tritt nämlich bei allen diesen von mir konvertierten und hochgeladenen Dateien auf:
- commons:Category:Diagrams of road signs of Switzerland, additional information signs (46 Dateien)
- commons:Category:Diagrams of road signs of Switzerland, danger symbols (31 Dateien)
- commons:Category:Diagrams of road signs of Switzerland, information symbols (123 Dateien)
- commons:Category:Diagrams of road signs of Switzerland, prescription symbols (93 Dateien)
- commons:Category:Diagrams of road signs of Switzerland, right of way symbols (16 Dateien)
- Weiß nicht, was beim Konvertieren schief gelaufen ist … Liebe Grüße, Debianux 20:36, 19. Jun. 2009 (CEST)
- Es muss nicht zwingend an der von mir ergänzten viewBox liegen. Bei WP:SVG#Mit Inkscape erstellte SVGs heißt es, dass ein fehlendes viewBox in der WP derzeit keine Probleme macht.
Durch das Kopieren des Logos in eine neue SVG-Datei bin ich auch die zwei transforms im Code losgeworden. Die Logos die ich mir Stichprobenweise angeschaut habe haben alle ihre eigentlichen Daten für die Zeichnung in zwei geschachtelten g-Tags jeweils mit transform-Anweisung. Ich gehe momentan davon aus, dass das der Knackpunkt für den Renderer des Wikis ist.
Ob das ändern ein Bot übernehmen kann weiß ich leider nicht. Viele Grüße --Marsupilami (Disk|Beiträge) 21:05, 24. Jun. 2009 (CEST)- Oder dann ist die ›Basisgröße‹ das Problem – vergleiche beispielsweise die von dir »korrigierte« Graphik rechts mit dieser hier. Liebe Grüße, Debianux 22:07, 24. Jun. 2009 (CEST)
- Es muss nicht zwingend an der von mir ergänzten viewBox liegen. Bei WP:SVG#Mit Inkscape erstellte SVGs heißt es, dass ein fehlendes viewBox in der WP derzeit keine Probleme macht.
- Ich würde mit der Diskussion auf die Diskussionsseite von WP:SVG umziehen. Viele Grüße --Marsupilami (Disk|Beiträge) 23:38, 24. Jun. 2009 (CEST)
- Ich habe dort eigentlich schon einen Hinweis hinterlassen. Soll ich diesen Abschnitt trotzdem dorthin kopieren? Liebe Grüße, Debianux 11:17, 25. Jun. 2009 (CEST)
- Das ist dann nicht nötig. So kommen hier auch ein paar SVG-ler vorbei. Viele Grüße --Marsupilami (Disk|Beiträge) 03:11, 28. Jun. 2009 (CEST)
- Ich habe dort eigentlich schon einen Hinweis hinterlassen. Soll ich diesen Abschnitt trotzdem dorthin kopieren? Liebe Grüße, Debianux 11:17, 25. Jun. 2009 (CEST)
- Ich würde mit der Diskussion auf die Diskussionsseite von WP:SVG umziehen. Viele Grüße --Marsupilami (Disk|Beiträge) 23:38, 24. Jun. 2009 (CEST)
Ich habe den Code der obig genannten SVG stark optimiert, das „zu schmal“ bezieht sich wahrscheinlich darauf, dass die Grafik nicht auf 180px in der Breite skaliert wird. Der Fehler hat nichts mit SVG oder RSVGLIB zu tun, vielmehr mit der Basisgröße der SVG-Datei. Marsupilami hat die Basisgröße der rechten, mittleren Grafik stark vergrößert (von ehemals 89px auf 558px) und deshalb wird diese nun auch korrekt auf 180px runtergerechnet. Hat nun eine SVG-Datei als Basisgröße eine wesentlich kleinere Breite als 180px rechnet MediaWiki die Grafikbreite nicht hoch auf 180px, da die Software davon ausgeht, dass es sich z. B. um eine GIF-, JPG- oder PNG-Datei handelt, die durch die Hochskalierung stark an Qualität verlieren würde. Der Trick ist also die Basisgröße der Dateien auf mindestens 180px zu setzen, oder wie ich auf 200px. LG, Fleshgrinder Diskussion 22:19, 30. Jun. 2009 (CEST)
- Ja genau, das habe ich mir gedacht. Da ich zu faul bin, den Trick auf 309 Graphiken anzuwenden, werde ich mal einen Bugreport ausfüllen. Liebe Grüße, Debianux 21:29, 3. Jul. 2009 (CEST)
- Die Grafik rechts wird im Firefox 3.0.x und 3.5 als SVG nicht mehr dargestellt. Viele Grüße --Marsupilami (Disk|Beiträge) 22:10, 3. Jul. 2009 (CEST)
- Korrigiert. Ein kleiner, aber feiner XML-Syntaxfehler: es fehlte die Angabe eines Standard-Namespace. Umso peinlicher, dass der W3C-Validator das nicht findet. --Hk kng 18:26, 4. Jul. 2009 (CEST)
- Das kann ja mal passieren bei den vielen SVG-Dateien die ich schon hochgeladen habe, hatte es nur im Opera angesehen und mit dem W3C-Validator gecheckt. Aber der Grund der falschen Skalierung ist definitiv so, wie von mir erläutert. LG, Fleshgrinder Diskussion 19:39, 4. Jul. 2009 (CEST)
- Ich habe einen Bugreport zum Validator geschrieben: [16] --Hk kng 00:13, 5. Jul. 2009 (CEST)
- Das kann ja mal passieren bei den vielen SVG-Dateien die ich schon hochgeladen habe, hatte es nur im Opera angesehen und mit dem W3C-Validator gecheckt. Aber der Grund der falschen Skalierung ist definitiv so, wie von mir erläutert. LG, Fleshgrinder Diskussion 19:39, 4. Jul. 2009 (CEST)
- Korrigiert. Ein kleiner, aber feiner XML-Syntaxfehler: es fehlte die Angabe eines Standard-Namespace. Umso peinlicher, dass der W3C-Validator das nicht findet. --Hk kng 18:26, 4. Jul. 2009 (CEST)
→ bugzilla:19633. Debianux 11:53, 10. Jul. 2009 (CEST)
relative Bildgröße
Hallo, kann man irgendwie die Größe eines Bildes relativ zur Textgröße machen? 1.3x1.0em als Größenangabe funktioniert leider nicht. Muss man da ein <div>-tag drumrum legen, welches die relative Größenangabe beherrscht? Hier wurde die Frage übrigens schonmal gestellt.
fragt -- ✓ Bergi 17:58, 23. Jul. 2009 (CEST)
- Warum will man das tun? -- smial disk 21:00, 23. Jul. 2009 (CEST)
- Bei irgendwelchen inline-Grafiken, z.B. Smileys in Diskussionen. Ist zwar ein bisschen viel Aufwand dafür, aber nur mal so gefragt…
meint -- ✓ Bergi 22:45, 23. Jul. 2009 (CEST)- Ich bin gerade dabei so etwas mit CSS und JavaScript zu implementieren. --Fomafix 22:50, 23. Jul. 2009 (CEST)
- Wenn <math>....</math> das könnte, das wäre schick. -- smial disk 00:24, 24. Jul. 2009 (CEST)
- Jo, dem kann ich mich auch nur anschließen, ¾÷5 sieht nunmal besser aus als … Der waagrechte Strich ist ja schön, aber wenns ein bisschen kleiner ginge, wäre das nur von Vorteil.
meint -- ✓ Bergi 11:49, 25. Jul. 2009 (CEST)- \tfrac: . -- seth 15:24, 25. Jul. 2009 (CEST)
- Jo, dem kann ich mich auch nur anschließen, ¾÷5 sieht nunmal besser aus als … Der waagrechte Strich ist ja schön, aber wenns ein bisschen kleiner ginge, wäre das nur von Vorteil.
- Wenn <math>....</math> das könnte, das wäre schick. -- smial disk 00:24, 24. Jul. 2009 (CEST)
- Ich bin gerade dabei so etwas mit CSS und JavaScript zu implementieren. --Fomafix 22:50, 23. Jul. 2009 (CEST)
- Bei irgendwelchen inline-Grafiken, z.B. Smileys in Diskussionen. Ist zwar ein bisschen viel Aufwand dafür, aber nur mal so gefragt…
Pressefoto
Darf ich ein Pressefoto hochladen, dass honorarfrei zur Verfügung gestellt wird? Die Künstler baten mich darum, und die Plattenfirma ist auch einverstanden. Von der Bildautorin, die diese pressefotos gemacht hat habe ich allerdings keine direkte Genehmigung (die Plattenfirma hat aber die Rechte). Wenn ja, wohin muss ich das Schreiben senden, in dem ich die Genehmigung erhalten habe? --92.117.60.45 11:01, 11. Aug. 2009 (CEST)
- Wikipedia:Urheberrechte_beachten: „In allen Fällen muss die Quelle bzw. die Zustimmung des Rechteinhabers an permissions-de@wikimedia.org weitergeleitet werden, falls sie nicht öffentlich im Internet einsehbar ist. … Eine Genehmigung des Rechteinhabers zur ‚Nutzung in der Wikipedia‘ oder ähnlich reicht nicht aus. Jede Veröffentlichung ist automatisch mit einer Lizenzierung unter CC-BY-SA und GFDL verbunden. … Bist du nicht der Urheber des eingestellten Werkes oder Textes, musst du beim Urheber eine Genehmigung zur Veröffentlichung unter CC-BY-SA und GFDL einholen. Unter Wikipedia:Textvorlagen finden sich hierfür Formbriefe. Auch die Antworten hierauf müssen an permissions-de@wikimedia.org weitergeleitet werden.“ Siehe auch Wikipedia:Support-Team#Bild-_und_Textfreigaben. Grüße, —DerHexer (Disk., Bew.) 11:07, 11. Aug. 2009 (CEST)
- Oh mein Gott, ist das alles kompliziert. Ich schau mal. Danke. --92.117.60.45 11:12, 11. Aug. 2009 (CEST)
Miniatur oder Thumbnail
Mahlzeit, liebe reverter! Sagt doch bitte mal, was eurer Meinung nach an meinem Beitrag falsch sein soll! Meinen alleruntertänigsten Dank! Und bitte verkneift euch sowas wie: das ist doch bloß `ne IP, die hat hier nix zu melden! Eure dankbare IP.--83.135.16.21 15:17, 15. Aug. 2009 (CEST)
- gudn tach!
- siehe /Archiv/2009#thumb und WP:Fragen_zur_Wikipedia/Archiv/2009/Woche_30#thumb_--.3E_miniatur.3F
- -- seth 15:39, 15. Aug. 2009 (CEST)
- Gelesen. Bloß hatte ich nicht geschrieben, das die englische Ausdrücke nicht verwendet werden dürfen. Ich hatte geschrieben, das besser der deutsche Ausdruck verwendet werden sollte. Wo zum Teufel ist das Problem?--83.135.16.21 15:46, 15. Aug. 2009 (CEST)
- Wer in andersprachigen WPs schreiben möchte, soll das tun. Deshalb hier fremdsprachige Ausdrücke benutzen zu bevorzugen, ist pervers (Und ich halte das für ein vorgeschobenes Argument)!--83.135.16.21 15:49, 15. Aug. 2009 (CEST)
- ich glaube dir nicht, dass du beides gelesen hast. es sind dort sogar meinungen vertreten, die sich komplett gegen versuchte eindeutschungen wie "miniatur" wenden. solange kein konsens herrscht, darf nicht irgendjemand einfach so die richtlinien aendern. sonst findet sich z.b. morgen jemand, der einfach die versucht-eingedeutschen begriffe wieder komplett verbannt mit dem hinweis auf einheitlichkeit. -- seth 16:00, 15. Aug. 2009 (CEST)
- Darf ich? Darf ich? -- smial 16:04, 15. Aug. 2009 (CEST)
- Wenn du magst. Kindergarden!--83.135.16.21 16:07, 15. Aug. 2009 (CEST)
- Kindergarten ist, mit Fußaufstampfen die eigene Position durchzusetzen. Oder es zu versuchen. -- smial 16:16, 15. Aug. 2009 (CEST)
- immerhin kann man sich in den preferences einen teil auf englisch umstellen. leider aber nicht alles, zumindest die lokalisierten url nerven (nicht nur) mich, aber wer weiss, wann sich daran was aendert, siehe bugzilla:9040. ansonsten kann wohl nur ein MB klarheit darueber bringen, wie (un)erwuenscht diese exzessive lokalisierung bei uns wirklich ist. -- seth 16:18, 15. Aug. 2009 (CEST)
- Wenn du magst. Kindergarden!--83.135.16.21 16:07, 15. Aug. 2009 (CEST)
- Darf ich? Darf ich? -- smial 16:04, 15. Aug. 2009 (CEST)
- ich glaube dir nicht, dass du beides gelesen hast. es sind dort sogar meinungen vertreten, die sich komplett gegen versuchte eindeutschungen wie "miniatur" wenden. solange kein konsens herrscht, darf nicht irgendjemand einfach so die richtlinien aendern. sonst findet sich z.b. morgen jemand, der einfach die versucht-eingedeutschen begriffe wieder komplett verbannt mit dem hinweis auf einheitlichkeit. -- seth 16:00, 15. Aug. 2009 (CEST)
Ich finde miniatur ist WP:OMA-freundlicher? Matthias 10:46, 14. Sep. 2009 (CEST)
Ich finde, bei thumb ist besser erkennbar, dass es sich nicht um Text der Bildunterschrift handelt. --Leyo 10:16, 18. Sep. 2009 (CEST)
- Das wird erst lustig, wenn jemand mal Kleinigkeiten auf anderen Wikis ändern möchte. In Ja wird anscheinend auch lokalisiert, da sehen Bilderlinks mal so [[画像:Sony a 350 with 18-70 kitlens.JPG|thumb|right|α350]], aber auch mal so [[Image:Sony_Alpha-700_img_1254.jpg|thumb|right|α700]] aus. Wenn da weitere Parameter in der Landessprache oder eben wie im Beispiel in anderen Zeichensätzen gesetzt werden, wird es allmählich widersinnig, z.B. wenn ich mal irgendwo ein untaugliches Bild austauschen und dabei von links nach rechts schieben möchte. Ein Benutzer aus Uganda oder Korea oder sonstwo wird möglicherweise in der deutschen WP vor ähnlichen Problemen stehen. Jedenfalls kann ich nicht erkennen, was daran benutzerfreundlicher sein soll. Wirklich benutzerfreundlich wäre es, wenn mir der Editor alle Schlüsselworte in meiner Sprache anzeigen würde, ich die in meiner Sprache bearbeiten könnte und die beim Speichern wieder automagisch in die ursrüngliche Sprache übersetzt würden. Die derzeitige Form der lokalisierung ist eine Krücke, die mehr Verwirrung schafft als auflöst. -- smial 11:58, 18. Sep. 2009 (CEST)
- In meinen Augen ist "miniatur" sowie "rechts" und "links" völliger unnützer Blödsinn. Es mach überhaupt keinen Sinn so etwas zu nutzen. Wie Smial es aufgeführt hat wird es besonders schwierig wenn man auf anderen wikis Bilder einfügen oder tauschen möchte. Oder wenn es ausländische Wikipedianer bei und auf "de" machen wollen. Ich selbst tue so etwas am laufenden Band und habe da ziemliche aber dann eigentlich total überflüssige Probleme. Für Wikipedia ist es außerdem völlig unwichtig. Hier sollten wir uns alles auf das wesentliche konzentrieren. Der Verwaltungskram soll nur Werkzeug sein. Jeder Minute die wir darüber hier diskutieren ist weggeworfene und vertane Zeit. Wacht doch mal endlich auf und vergeudet Eure Zeit nicht mit unwichtigem!!! --Alchemist-hp 14:02, 18. Sep. 2009 (CEST)
- Es wird aber auch immer gerne vergessen, das MediaWiki auch für andere Verfügbar ist. Dabei kann es sein, das ein privates Wiki keine anderen Sprachversionen hat, es ist somit mit den deutschsprachigen Bezeichnungen bestens zufrieden. Mit den unterschiedlichen Sprachversionen ist es natürlich etwas schwierig, wenn man dort etwas herauskopieren möchte. Möchte man etwas einfügen, gehen immer die englischen, es ist also unproblematisch. Abgucken geht auch: Bilder im Artikelnamensraum führen immer auf die Bildbeschreibungsseite, wo man den Bildnamen einfach wegkopieren kann und dann damit im Quelltext suchen kann. Alles bis zum ersten Doppelpunkt ist Namensraum. Eventuell ist es ein Commonsbild, dann klickt man einfach sich dorthin und die englischen Aliase kennt man ja. Ist natürlich nicht so einfach, wie nur bei englischsprachigen Begriffen, aber man kann sich sicher damit Arangieren, denke ich. Der Umherirrende 16:27, 18. Sep. 2009 (CEST)
- Ja, klar. Arrangieren. Irgendwie. Und in der vietnamesischen Wikipedia werde ich dann möglicherweise als Vandale gesperrt bzw. meine inhaltlichen Änderungen stumpf revertiert, weil ich bei einer paar Bildern das lokalisierte "File", "left", "thumb" usw. aus Nichtkenntnis der Sprache gegen die englischen Begriffe ausgetauscht habe, nur weil ich einige aktuellere oder bessere Kirchenfotos einbauen wollte? Ich trampele, ehrlich gesagt, sehr ungerne auf Konventionen anderer Leute oder gar Kulturkreisen herum. Und, wenn es wirklich nützlich sein soll, müßte es dann nicht kreuz und quer durch alle Sprachen klappen? -- smial 16:52, 18. Sep. 2009 (CEST) Ps.: Wenn man die englischen Aliase eh kennt (kennen muß), dann kann man die auch gleich nehmen. Mickeysoft hat die deutschen Übersetzungen für Excel-Makros und -befehle afair ja auch wieder rausgenommen. Die werden ihre Gründe gehabt haben.
- Bei Excel klappt die Methodik, die du oben angedeutet hast. Wenn man die Oberflächensprache von Excel ändert, dann ändern sich auch die Namen der Befehle (ob das bei Makro-Befehle auch klappt weiß ich nicht). Die englischen Befehle funktionieren beispielsweise nicht mit deutschsprachiger Oberfläche. Ob das für MediaWiki auch umsetzbar ist, mag ich nicht sagen. Der Umherirrende 17:04, 18. Sep. 2009 (CEST)
- Ja, klar. Arrangieren. Irgendwie. Und in der vietnamesischen Wikipedia werde ich dann möglicherweise als Vandale gesperrt bzw. meine inhaltlichen Änderungen stumpf revertiert, weil ich bei einer paar Bildern das lokalisierte "File", "left", "thumb" usw. aus Nichtkenntnis der Sprache gegen die englischen Begriffe ausgetauscht habe, nur weil ich einige aktuellere oder bessere Kirchenfotos einbauen wollte? Ich trampele, ehrlich gesagt, sehr ungerne auf Konventionen anderer Leute oder gar Kulturkreisen herum. Und, wenn es wirklich nützlich sein soll, müßte es dann nicht kreuz und quer durch alle Sprachen klappen? -- smial 16:52, 18. Sep. 2009 (CEST) Ps.: Wenn man die englischen Aliase eh kennt (kennen muß), dann kann man die auch gleich nehmen. Mickeysoft hat die deutschen Übersetzungen für Excel-Makros und -befehle afair ja auch wieder rausgenommen. Die werden ihre Gründe gehabt haben.
Das Ganze erinnert mich an Übersetzungen von Skripten, bei denen man versehentlich die Befehle mitübersetzt hat. *g* Mbdortmund 14:30, 19. Sep. 2009 (CEST)
WTF!? Die Gemeindemitglieder mögen sich bitte erinnern: wer standardmäßig (und auf allen Ebenen) lieber english verwendet, dem steht die WP:EN zur freien Verfügung. Und die braucht gute Leute, oh my!! BvB sucks! [;-)] Gruß -- MfG Wikifantexter Alles Roger? 18:41, 21. Sep. 2009 (CEST)
Hinweis zur Verwendung der Option „Großes Bild“
Hallo,
hiermit möchte ich auf folgenden Hinweis aufmerksam machen, um den ich den entsprechenden Abschnitt ergänzt habe. Gruß – Wladyslaw [Disk.] 13:44, 29. Jun. 2009 (CEST)
- Warum soll
{{Panorama|Panorama Schwerin Wasserturm Neumuehle.jpg|2000|Panoramabild Schwerins}}
eine größere Barriere als[[Bild:Panorama Schwerin Wasserturm Neumuehle.jpg|2000px|thumb|center|Panoramabild Schwerins]]
darstellen? --Fomafix 13:57, 29. Jun. 2009 (CEST)
- Die Verwendung von 2000 Pixel als Breite bei einem Panoramabild ist nicht notwendig. Es reicht vollkommen diese Bilder mit 750px einzubinden. – Wladyslaw [Disk.] 14:01, 29. Jun. 2009 (CEST)
- Das Spricht aber alles nicht gegen die Vorlage:Großes Bild.
{{Panorama|Panorama Schwerin Wasserturm Neumuehle.jpg|750|Panoramabild Schwerins}}
geht genauso. --Fomafix 14:40, 29. Jun. 2009 (CEST)
- Diese Vorlage erzeugt Scrollbalken und diese sind nicht barrierefrei. Die Vorlage Großes Bild mit einer Bildbreite von 750 px läuft letztlich auf die von mir vorgeschlagene (reguläre) Lösung hinaus. Und diese hat den Vorteil, dass keine Scrollbalken auftauchen wenn man das Bild anklickt. Es gibt m.E. nur sehr wenige Bilder, wo diese Vorlage sinnvoll ist und ich trotz der Nichteinhaltung der Barrierefreiheit die Anwendung gut finde und zwar bei Bildern mit extremen Sonderformaten wie Datei:Vicke Schorler Rolle.jpg. Die allermeisten Panoramabilder sind mit der konventionellen Einbindung bestens bedient und für alle Benutzer gleichermaßen verwendbar. – Wladyslaw [Disk.] 14:45, 29. Jun. 2009 (CEST)
- Eine 750er Version ist einer 2000er immer vorzuziehen. 2000er schafft für schätzungsweise 99% der Besucher eine Barriere. Und eine Lösung ohne Scrollbalken ist ebenso immer bevorzugt zu verwenden. --Marcela 15:25, 29. Jun. 2009 (CEST)
- Kurze Ergänzung: statt 750px habe ich die äquivalente Lösung ohne feste Bildbreite von upright=4.0 gewählt. – Wladyslaw [Disk.] 15:28, 29. Jun. 2009 (CEST)
- Ich hab den Hinweis noch mal angepasst ("miniatur" eingefügt). Gibt's für Bilder vielleicht so einen Parameter wie bei Tabellen, dass mann die Breite auf 100% festsetzen kann ? Dann fände ich das ja noch besser, weil dann immer der Bildschirm optimal genutzt würde. --n8eule78 16:19, 29. Jun. 2009 (CEST)
- Meinst Du 100 % von der Bildschirmbreite? So eine Option ist mir nicht bekannt. Ich denke aber, dass man für das Panoramabildproblem mit upright=4.0 ganz gut fährt. – Wladyslaw [Disk.] 16:32, 29. Jun. 2009 (CEST)
- Ich hab den Hinweis noch mal angepasst ("miniatur" eingefügt). Gibt's für Bilder vielleicht so einen Parameter wie bei Tabellen, dass mann die Breite auf 100% festsetzen kann ? Dann fände ich das ja noch besser, weil dann immer der Bildschirm optimal genutzt würde. --n8eule78 16:19, 29. Jun. 2009 (CEST)
- Kurze Ergänzung: statt 750px habe ich die äquivalente Lösung ohne feste Bildbreite von upright=4.0 gewählt. – Wladyslaw [Disk.] 15:28, 29. Jun. 2009 (CEST)
- Eine 750er Version ist einer 2000er immer vorzuziehen. 2000er schafft für schätzungsweise 99% der Besucher eine Barriere. Und eine Lösung ohne Scrollbalken ist ebenso immer bevorzugt zu verwenden. --Marcela 15:25, 29. Jun. 2009 (CEST)
- Wenn man "Großes Bild" auf 750px festnagelt, wird der Scrollbalken halt bei kleineren Bildschirmen oder Fenstern auftreten, vermieden wird der nicht. Außerdem wird der "aufrecht"-Parameter nicht verstanden. Von mir aus kann "Großes Bild" und "Große Imagemap" gerna auch ganz weg. -- smial disk 17:19, 29. Jun. 2009 (CEST)
- mir wärs ja am liebsten, wenn der wikiparser selbst bei über etwa 400px einen scrollbalken einblendet - die 750px maximalbreite werden nicht gut angenommen, insbesonsders leuchten sie der jungen generation, für die schon 1024px bildschirmbreite mikrig sind, und schrecklich viel "ungenutzter" leerer raum neben einem 750px-bild liegt, und für die papier ein fremdwort ist, gar nicht ein - es wird wirklich mal zeit, zumindest unseren pdf-export als breiten-richtlinie zu etablieren --W!B: 02:42, 30. Jun. 2009 (CEST)
- Die Vorlage erzeugt nur Scrollbalken, wenn das Bild breiter ist als das Browserfenster. Das macht der Browser selbst auch, nur macht er den Scrollbalken am Ende des Fensters. Barrierefreiheit kann also hier kein Argument sein.
upright=4.0
ist sicherlich besser als750px
. Die Vorlage Großes Bild kann leider mit upright nicht rechnen, da MediaWiki die Benutzereinstellung leider nicht weitergibt. Vielleicht fällt mir aber noch was ein. Wahrscheinlich müsste diese Funktion direkt in MediaWiki eingebaut werden.- Das Verbot der Vorlage Großes Bild aufgrund der Barrierefreiheit ist falsch und kann so nicht stehen bleiben. --Fomafix 11:23, 30. Jun. 2009 (CEST)
- Mit HTML lässt übrigens ein Bild in der Breite des Browserfensters erzeugen: . Das Bild verkleinert sich automatisch, wenn das Fenster verkleinert wird. Leider filtert MediaWiki so etwas aus dem Wikicode heraus. Wir könnten es aber über eine CSS-Klasse in MediaWiki:Common.css durchmogeln:
<img width="100%" src="http://upload.wikimedia.org/wikipedia/commons/thumb/6/65/Panorama_Schwerin_Wasserturm_Neumuehle.jpg/750px-Panorama_Schwerin_Wasserturm_Neumuehle.jpg" alt="Panoramabild Schwerins" />
--Fomafix 12:44, 30. Jun. 2009 (CEST).panorama img { width: 100%; height:auto }
- Ich habe in die Vorlage:Großes Bild die CSS-Klasse
panorama
eingefügt. Damit kann sich jeder selbst die gewünschte Darstellung einstellen. Der Autor legt nur fest, dass es sich hier um ein Großes Bild (Panorama) handelt und legt die genaue Darstellung nicht fest. Damit sichert die Vorlage sogar die Barrierefreiheit. --Fomafix 13:37, 30. Jun. 2009 (CEST)- CSS ist immer gut - in der MediaWiki:Common.css ist
panorama
nicht deklariert, wo steht die? sie sollte wohl nicht skin-spezifisch deklariert sein --W!B: 01:37, 4. Jul. 2009 (CEST)- Die CSS-Klasse
panorama
teste ich im Moment in meiner CSS-Datei. Parallel entwickle ich ein Gadget mit dem der Zoom beim Anzeigen eingestellt werden kann. Wenn alles funktioniert, kann in die Einstellung MediaWiki:Common.css übernommen oder als Gadget zur Verfügung gestellt werden. Idealerweise sollten die Erkenntnisse in MediaWiki übernommen werden und damit die Vorlage:Großes Bild überflüssig machen. Den Hinweis der Hilfeseite werde ich entfernen, nicht dass ein Regelhuber aus diesem Grund die Vorlage entfernt. --Fomafix 14:48, 5. Jul. 2009 (CEST)- Entfernung rückgängig gemacht, da ich dafür keinerlei Grundlage sehe. Ein „Regelhuber“ kann diese Vorlage nämlich auch ohne diesen Hinweis entfernen. Und sofern Panoramen in Artikeln derart eingebunden waren, dass sie mit 2000px oder mehr die Breite einer Standardeinstellung gesprengt habe, habe ich diese Vorlage ohnehin immer durch eine andere Darstellung ersetzt. Wie ich bereits sagte sehe ich die Vorlage als sinnvolle Möglichkeit für Sonderformate an, aber stehe ihrer Verwendung im Artikelraum sonst kritisch bis ablehnend gegenüber. – Wladyslaw [Disk.] 16:29, 5. Jul. 2009 (CEST)
- Bitte keine persönlichen Regeln aufstellen. --Fomafix 17:04, 5. Jul. 2009 (CEST)
- Eine nicht barrierefreie Vorlage, die hier auch von anderen Benutzern als nicht optimal bezeichnet wird hat nichts mit einer persönlichen Regel zu tun. Bitte keine privaten Programme gegen den Willen der Gemeinschaft durchdrücken. – Wladyslaw [Disk.] 19:15, 5. Jul. 2009 (CEST)
- Dann bitte konstruktive Vorschläge bringen. Die Vorlage stammt weder von mir noch habe ich sie in Artikel eingebaut. Solange MediaWiki keine geeignete Unterstützung für große Bilder bietet ist diese Vorlage ein geeignete Kompromiss. Wenn es Probleme damit gibt, dann aufzeigen, damit sie gelöst werden. Solange gilt Friedenspflicht und raus mit dem Hinweis. --Fomafix 20:31, 5. Jul. 2009 (CEST)
- Der konstruktive Vorschlag ist in dem Hinweis enthalten. Mit Ausnahme der angesprochenen Sonderformate besteht für diese Vorlage kein Anwendungsgebiet. Panoramen lassen sich hervorragend ohne diese Funktion in Artikel setzen. Das Problem, welches durch die Vorlage entsteht wurde bereits dargelegt. – Wladyslaw [Disk.] 20:41, 5. Jul. 2009 (CEST)
- Dann bitte konstruktive Vorschläge bringen. Die Vorlage stammt weder von mir noch habe ich sie in Artikel eingebaut. Solange MediaWiki keine geeignete Unterstützung für große Bilder bietet ist diese Vorlage ein geeignete Kompromiss. Wenn es Probleme damit gibt, dann aufzeigen, damit sie gelöst werden. Solange gilt Friedenspflicht und raus mit dem Hinweis. --Fomafix 20:31, 5. Jul. 2009 (CEST)
- @Fomafix: Der konstruktive Vorschlag wurde bereits gemacht (thumb mit upright >1), das Problem wurde bereits aufgezeigt (nicht barrierefrei) und durch den gemachten Vorschlag auch schon gelöst. Unfriedlich scheint mir zu sein, eine bereits diskutierte, sinnvolle Erweiterung der Hilfe rauszupöhlen. -- smial disk 21:21, 5. Jul. 2009 (CEST) Ps: scrollst Du bitte einmal ein "Großes Bild" ohne Mausbedienung horizontal? Wieviele Tastendrucke benötigst du dorthin? Wieviele Tastendrucke benötigst du, um das ganze Browserfenster horizontal zu scrollen?
- Wenn ein Leser keine Maus verwendet, dann bewegt er sich auch mit Tasten von Link zu Link. Sobald er auf einem Element mit scrollbaren Inhalt ist, kann dieser Bereich gescrollt werden. Es ist somit keine zusätzlichen Tastendrücke notwendig. Das Argument Barrierefreiheit ist kann somit kein Grund sein.
- Ziel der Vorlage ist es dem Autor eine Möglichkeit zu geben sehr breite Bilder zu verwenden, ohne sich über die browserspezifischen Eigenheiten Gedanken machen zu müssen. Scrollbalken ist nur eine Möglichkeit der Darstellung. Eine andere ist es, die Bilder auf die Fensterbreite zu verkleinern. Ich bin gerade dabei eine Erweiterung und entwickeln und zu testen, um Scrollbalken zu vermeiden. Mithilfe ist gerne erwünscht. Ein Entfernen der Vorlage aus den Artikeln ist aber kontraproduktiv. Die Vorlage kann ersetzt werden, wenn in MediaWiki eine entsprechende Erweiterung existiert. --Fomafix 22:30, 5. Jul. 2009 (CEST)
- Eine nicht barrierefreie Vorlage, die hier auch von anderen Benutzern als nicht optimal bezeichnet wird hat nichts mit einer persönlichen Regel zu tun. Bitte keine privaten Programme gegen den Willen der Gemeinschaft durchdrücken. – Wladyslaw [Disk.] 19:15, 5. Jul. 2009 (CEST)
- Bitte keine persönlichen Regeln aufstellen. --Fomafix 17:04, 5. Jul. 2009 (CEST)
- Entfernung rückgängig gemacht, da ich dafür keinerlei Grundlage sehe. Ein „Regelhuber“ kann diese Vorlage nämlich auch ohne diesen Hinweis entfernen. Und sofern Panoramen in Artikeln derart eingebunden waren, dass sie mit 2000px oder mehr die Breite einer Standardeinstellung gesprengt habe, habe ich diese Vorlage ohnehin immer durch eine andere Darstellung ersetzt. Wie ich bereits sagte sehe ich die Vorlage als sinnvolle Möglichkeit für Sonderformate an, aber stehe ihrer Verwendung im Artikelraum sonst kritisch bis ablehnend gegenüber. – Wladyslaw [Disk.] 16:29, 5. Jul. 2009 (CEST)
- Die CSS-Klasse
- CSS ist immer gut - in der MediaWiki:Common.css ist
- Ich habe in die Vorlage:Großes Bild die CSS-Klasse
- Mit HTML lässt übrigens ein Bild in der Breite des Browserfensters erzeugen:
- mir wärs ja am liebsten, wenn der wikiparser selbst bei über etwa 400px einen scrollbalken einblendet - die 750px maximalbreite werden nicht gut angenommen, insbesonsders leuchten sie der jungen generation, für die schon 1024px bildschirmbreite mikrig sind, und schrecklich viel "ungenutzter" leerer raum neben einem 750px-bild liegt, und für die papier ein fremdwort ist, gar nicht ein - es wird wirklich mal zeit, zumindest unseren pdf-export als breiten-richtlinie zu etablieren --W!B: 02:42, 30. Jun. 2009 (CEST)
- Diese Vorlage erzeugt Scrollbalken und diese sind nicht barrierefrei. Die Vorlage Großes Bild mit einer Bildbreite von 750 px läuft letztlich auf die von mir vorgeschlagene (reguläre) Lösung hinaus. Und diese hat den Vorteil, dass keine Scrollbalken auftauchen wenn man das Bild anklickt. Es gibt m.E. nur sehr wenige Bilder, wo diese Vorlage sinnvoll ist und ich trotz der Nichteinhaltung der Barrierefreiheit die Anwendung gut finde und zwar bei Bildern mit extremen Sonderformaten wie Datei:Vicke Schorler Rolle.jpg. Die allermeisten Panoramabilder sind mit der konventionellen Einbindung bestens bedient und für alle Benutzer gleichermaßen verwendbar. – Wladyslaw [Disk.] 14:45, 29. Jun. 2009 (CEST)
- Also ich hab noch keinen genaue Erklärung dafür gefunden wieso die Vorlage nicht Barrierefrei sein soll. Das Einbinden von Panorama-Bildern im "Mini-Format" in einer Größe von 750px ist vollkommen sinnlos da nur etwas erkennbar ist wenn man das Bild öffnet und für den Fall kann man das Bild auch einfach verlinken. --DaSch/Feuerwehrkontrolle 15:42, 24. Aug. 2009 (CEST)
- Die Jetzt als Alternative Vorgeschlagene Option produziert z.B. sowas
Das ist echt fatal. Außerdem bringt die Festlegung der Breite auf 750px ein eigentlich viel größeres Problem. Auf Bildschirmen mit nur 800px oder weniger (die wieder versträkt Verbreitung finden). Erscheint ein Horizontaler Scrollbalken der noch viel unschöner ist als der Scrollbalken im Bild selbst. Da kann dann nämlich jede Zeile nur mit Hilfe des Scrollbalkens gelesen werden. Durch die einheitliche Verwendung des Vorlage Großes Bild kann man mit zusätzlicher Formatierung dann noch Optionen für Mobile Geräte bereitstellen und jeder Benutzer kann sich auch zusätzliche Optionen hinzufügen. Wenn jeder Panoramas nach seine Ideen formatiert haben wir nur Chaos! --DaSch/Feuerwehrkontrolle 15:50, 24. Aug. 2009 (CEST)
- Dann solltest einfach mal genauer lesen. Die Vorlage erstellt einen Scrollbalken und diese sind nicht barrierefrei. Das „Mini-Format“ geht fast über die ganze Artikelbreite, als mini kann ich das nicht bezeichnen und das Bild ist im thumb eindeutig als Panorama zu erkennen. Will man näheres ansehen klickt man das Bild an. Es ist nicht die Aufgabe des Artikels Bilder im Großformat zu präsentieren. Wir schreiben in erster Linie Artikel und keine Bilderbücher. – Wladyslaw [Disk.] 15:46, 24. Aug. 2009 (CEST)
- Das ist doch unsinnig. Dann können wir auch gleich sowas machen: [[:Datei:Toronto panorama.jpg|360-Grad-Blick vom CN Tower]]! Dann kann man auch irgendein "standardpanorama" nehmen und dann auf das jeweils richtige Verlinken. Wenn man nichts auf dem Bild erkennt hat es im Artikel nichts verloren. Die Vorlage erstellt aber nicht aus Prinzip einen Scrollbalken. Außerdem ist ein horizontaler Scrollbalken über die ganze Seitenbreite barrierefrei? Also das ist eine Frage der Abwägung ob man alle Netbookbesitzer vor den Kopf stoßen will oder ein paar Leute, die wieso auch immer keine horizontalen Scrollbalken innerhalb von divs verwenden können. Was du immer noch nicht erklärt hat wieso das genau nicht funktioniert. --DaSch/Feuerwehrkontrolle 15:58, 24. Aug. 2009 (CEST)
- Was soll daran unsinnig sein, für ein Panorama eine ganze Artikelbreite zu opfern, so wie es derzeit auch im Artikel implementiert ist? Auf dem Bild lässt sich erkennen, dass man die Stadt unterhalb des Turms sieht. Für Einzelheiten ist die Großansicht zuständig. Wo siehst Du in der jetztigen Fassung einen horizontalen Scrollbalken? Was du immer noch nicht erklärt hat wieso das genau nicht funktioniert. Die dazugehörige Frage kenne ich nicht. – Wladyslaw [Disk.] 16:01, 24. Aug. 2009 (CEST)
- so sieht das auf einem Netbook aus! Wenn du einfach nur irgendwo gelesen hast dass Scrollbalken nicht barrierefrei sind aber nicht mal eine genaue Erklärung dafür hast dann gibt es meiner Ansicht nach keinen Grund die Vorlage nicht zu benutzen. Ansonsten gäbe es vielleicht eine Möglichkeit die Vorlage in dieser Hinsicht zu verbessern, aber ohne was konkretes geht das nicht. Außerdem, über die Vorlage kann man über sein persönliches CSS eine Alternative Darstellung, die auch dem von die Vorgeschlagenen entspricht. --DaSch/Feuerwehrkontrolle 16:23, 24. Aug. 2009 (CEST)
Mal so als Frage: Wo ist denn das hier genannte System ohne Maus im Einsatz? --Cobelius 19:58, 24. Aug. 2009 (CEST)
- Es existieren Menschen mit eingeschränkten Möglichkeiten, denen die Bedienung der Maus sehr schwer fällt. Solch einen Scrollbalken mitten im Fenster zu treffen, fällt denen schon mal recht schwer. Diese benutzen lieber die Tastatur oder andere Eingabemöglichkeiten. -- smial 20:10, 24. Aug. 2009 (CEST)
- Der Scrollbalken lässt sich auch mit Pfeiltasten steuern wenn das Bild markiert ist. Es reicht also auch ein klick auf den Rahmen, falls man eine Maus hat, damit aber nicht präzise Zielen kann. Wenn man keine Maus hat muss man per Tab durch den Artikel, das muss man aber auch um Links aufzurufen oder das Bild in einer größeren Version anzuschauen. --DaSch/Feuerwehrkontrolle 20:16, 24. Aug. 2009 (CEST)
- Das ist immernoch sehr hypothetischer Natur gerade. Von welchen Einschränkungen reden wir hier und welche alternativen Eingabemöglichkeiten? --Cobelius 20:13, 24. Aug. 2009 (CEST)
- Also nochmal langsam zum mitschreiben: niemand bestreitet (auch ich habe das nie getan), dass man für nahezu jede Form der Barriere eine (meist umständliche) Alternative findet, diese zu umgehen. Es geht also nicht darum: was ist machbar sondern was ist vermeidbar, um Menschen mit Behinderungen den Umgang mit unseren Seiten so wenig umständlich wie möglich zu machen. Dass ein gesunder Mensch von „hypothetischen“ Überlegungen spricht, da er selbst nicht behindert ist und vielleicht auch nie sein wird ist für diejenigen, die es sind geradezu höhnisch. Zumal die dargestellten Panoramen ohne diese Vorlage für „gesunde“ Menschen völlig frei von irgendwelchen Einschränkungen sind. Das heißt im Umkehrschluss die Umstände, welche von dieser Vorlage ausgeht ist weitaus größer als ihr nutzen, denn es geht schließlich auch ohne sie. – Wladyslaw [Disk.] 21:16, 24. Aug. 2009 (CEST)
- Da hast Du mich falsch verstanden,ich nehme solche Dinge (aufgrund einiger Fälle in meiner Familie) sehr ernst. Allerdings ist es wenig Zielgerichtet zu sagen: "Es gibt bestimmte Behinderungen wo Menschen sowas nicht benutzen können", ohne dabei konkret zu werden. Ohne konkretisierung, bleibt die Sache halt ebend hypothetisch und somit verkommt die wichtige Diskussion zu einem Austausch von Totschlagargumenten. In meinem Studium hatte wir sowas auch durchgenommen und es gibt Eingabesysteme, die hätte selbst gerne. --Cobelius 21:24, 24. Aug. 2009 (CEST)
- Ich gebe Dir insofern Recht, dass die Redaktion BIENE vielleicht sogar diese Diskussion zum Anlass nehmen sollte, einen Katalog an No-Gos und wünschenswerten Formatierungen für Wikipedia-Artikel zu entwerfen und anhand von Praxisfällen das Bewusstsein für dieses Thema zu schärfen. Vielleicht kann das Ralf in die Wege leiten, da er dort u.a. tätig ist. Ich bin kein Experte auf dem Gebiet der BF, mir liegt das Thema dennoch am Herzen. – Wladyslaw [Disk.] 21:41, 24. Aug. 2009 (CEST)
- Genau so sehe ich das auch. Wegen hypothetischen Barrieren die Useability für alle einzuschränken ist echt traurig. Besonders, wie ich immer wiederhole, können sich Personen die damit wirklich nicht umgehen können mit einem Benutzerkonto über die css-class Panorama eine alternative Formatierung einfügen. Außerdem Wladyslaw, probier mal ohne die Maus zu benutzen einen Link aus dem Abschnitt Meiden im Artikel Toronto zu öffnen. Ich frag mich was du dann zum Thema Barrierefreiheit von Links sagt. Oder versuch das Bild aufzumachen, schließlich willst du es dir in voller Größe anzuschauen. Wenn du schon das Bild mit Tab markiert hast dann kannst du es öffnen oder auch scrollen. Probier es einfach mal aus. Vielleicht kommst du dann dazu dass es eigentlich keinen Unterschied in der Bedienung macht. Außer bei einem Screenreader oder bei Sprachsteuerung weiß ich nicht wie sich das verhält. --DaSch/Feuerwehrkontrolle 21:44, 24. Aug. 2009 (CEST)
- Vielleicht solltest Du Dir das Posting von Cobelius genauer durchlesen, bevor Du es als Argument für Dich ummünzt, obwohl es keines ist. Aber mit dem Lesen hast Du scheinbar so manche Probleme. Man muss nicht einmal behindert sein sondern von PC nicht viel Ahnung haben, um nicht zu wissen, was eine css-class ist geschweige denn, dass wir von unseren Lesern nicht zu erwarten haben, dass sie sich erst anmelden und am css-Sheet herumzubasten haben, damit sie alles so sehen können wie sie es auch sehen könnten wenn von vorn herein darauf geachtet wird. Und selbstverständlich wird die Useability kein Deut eingeschränkt, wenn man ein Panorama sogar auf Artikelbreite zieht sonst müsste ich mich noch genötigt fühlen 20-MB-Bilder wie Datei:Keswick, Cumbria Panorama 1 - June 2009.jpg auf 100 % zu skalieren weil ich da auch nicht jedes Schaf in der regulären Artikelansicht anschauen kann. Aber wie ich bereits sagte: wir schreiben hier eine Enzyklopädie, die mit Bildern aufgewertet wird und nicht ein Bilderbuch mit ein bisschen Text zwischenrein – auch wenn das manche verwechseln. Und nun ist zu diesem Thema wahrlich genug gepostet worden. – Wladyslaw [Disk.] 21:53, 24. Aug. 2009 (CEST)
- Ich würde dich trotzdem darum bitten auch andere Funktionen außer dem scrollen von Bildern ohne Maus auszuprobieren. Also Links öffnen. Das kleine Panorama in voller Größe öffnen. Das alles halt ohne Maus. Nur um das Verhältnis zwischen der Panorama-Scrollbalken-Barriere und den anderen alltäglichen normalen Barrieren zu erfahren. Damit du etwas Praxiserfahrung in dem Bereich sammelst. --DaSch/Feuerwehrkontrolle 22:03, 24. Aug. 2009 (CEST)
- Vielleicht solltest Du Dir das Posting von Cobelius genauer durchlesen, bevor Du es als Argument für Dich ummünzt, obwohl es keines ist. Aber mit dem Lesen hast Du scheinbar so manche Probleme. Man muss nicht einmal behindert sein sondern von PC nicht viel Ahnung haben, um nicht zu wissen, was eine css-class ist geschweige denn, dass wir von unseren Lesern nicht zu erwarten haben, dass sie sich erst anmelden und am css-Sheet herumzubasten haben, damit sie alles so sehen können wie sie es auch sehen könnten wenn von vorn herein darauf geachtet wird. Und selbstverständlich wird die Useability kein Deut eingeschränkt, wenn man ein Panorama sogar auf Artikelbreite zieht sonst müsste ich mich noch genötigt fühlen 20-MB-Bilder wie Datei:Keswick, Cumbria Panorama 1 - June 2009.jpg auf 100 % zu skalieren weil ich da auch nicht jedes Schaf in der regulären Artikelansicht anschauen kann. Aber wie ich bereits sagte: wir schreiben hier eine Enzyklopädie, die mit Bildern aufgewertet wird und nicht ein Bilderbuch mit ein bisschen Text zwischenrein – auch wenn das manche verwechseln. Und nun ist zu diesem Thema wahrlich genug gepostet worden. – Wladyslaw [Disk.] 21:53, 24. Aug. 2009 (CEST)
- Es gibt es eigentlich keine ernstzunehmenden Bedenken gegen die Vorlagen wenn ich das richtig sehe. Es gibt keine stichhaltigen Beweise dafür, dass die Vorlage wirklich die Barrierefreiheit einschränkt. --DaSch/Feuerwehrkontrolle 23:27, 24. Aug. 2009 (CEST)
- Doch, die gibts. Installiere dir Jaws, dann siehst (hörst) du es. Als weiterführende Literatur empfehle ich WP:BIENE --Marcela 00:25, 25. Aug. 2009 (CEST)
Nein, ihr geht immernoch falsch an die Sache ran. Ihr müsst euch folgende Fragen stellen und zwar in der Reihenfolge:
- Gibt es Behinderungen, die ein Scrollen mit der Maus erheblich erschweren oder unmöglich machen, sodass der Benutzer diese nicht verwenden kann? Wenn ja, welche sind das und wieviele Personen leiden darunter.
- Welche der in der vorherigen erfassten Personengruppen kann ihre Behinderung durch Board-Mittel des Betriebssystems ausgleichen? Welche Möglichkeiten haben die drei großen Systeme Leute mit exakt diesen behinderungen zu unterstützen, gleichen diese Eingabehilfen des Betriebssystems die Maus aus?
- Wieviele sind es, deren Einschränkungen so stark sind, dass ihnen auch die betriebssystemeigenen Eingabehilfen nicht mehr helfen können?
- Welche Eingabesystem gibt es dann für diese Gruppe von Leuten (z.B. Eye-Tracker), was können diese im Bezug auf das Problem des scrollens von Bildern? Und wie verbreitet sind solche Systeme in der identifizierten Gruppe.
Am Ende dieses Prozesses wird man dann verlässlich sagen können, ob es eine Gruppe gibt, die die o.g. Bilder nicht scrollen kann oder ob es diese nicht gibt, weil Eingabehilfen der Betriebssysteme entsprechend gut sind oder andere Eingabegeräte nicht verfügbar sind oder zu teuer sind. Alles andere ist Spekulation und Diskussion um der Diskussion willen. --Cobelius 09:59, 25. Aug. 2009 (CEST)
- Es sieht mir ganz danach aus, dass die hier vorgebrachten Probleme rein hypothetischer Natur sind. Auch meine Recherchen zum dem Thema haben nichts ergeben. Solange es also keine nachvollziehbaren und stichhaltigen Beweise gibt, dass die Vorlage nicht barrierefrei ist, ist sie als solche zu betrachten und damit die Verwendung in Artikel zulässig. --DaSch/Feuerwehrkontrolle
- Das legst du aber nicht allein fest, solange du da im Abseits stehst. das ist allein deine Sichtweise der Sache und kein Konsens. --Marcela 15:31, 14. Sep. 2009 (CEST)
- Also aus der Diskussion kann ich entnehmen dass ich damit nicht alleine stehe. Die hier aufgeführten Bedenken sind rein hypothetischer Natur und sind nicht nachvollziehbar oder beweisbar. Es ist immer noch nicht klar dargestellt worden ob durch die Vorlage überhaupt eine Beeinträchtigung der Bedienbarkeit besteht. Was hier vorgetragen wurden sind nur Bedenken, aber keine Tatsachen. --DaSch/Feuerwehrkontrolle 15:44, 14. Sep. 2009 (CEST)
- Dann installiere dir endlich JAWS und versuche es selbst mal. -Marcela 15:48, 14. Sep. 2009 (CEST)
- Also aus der Diskussion kann ich entnehmen dass ich damit nicht alleine stehe. Die hier aufgeführten Bedenken sind rein hypothetischer Natur und sind nicht nachvollziehbar oder beweisbar. Es ist immer noch nicht klar dargestellt worden ob durch die Vorlage überhaupt eine Beeinträchtigung der Bedienbarkeit besteht. Was hier vorgetragen wurden sind nur Bedenken, aber keine Tatsachen. --DaSch/Feuerwehrkontrolle 15:44, 14. Sep. 2009 (CEST)
- Das legst du aber nicht allein fest, solange du da im Abseits stehst. das ist allein deine Sichtweise der Sache und kein Konsens. --Marcela 15:31, 14. Sep. 2009 (CEST)
- Ralf, pass am besten mal auf, dass DaSch das jetzt nicht per Bugzilla von hintenrum einkippt. Über den Weg hat er uns auch schon mit einem falschen Tausendertrennzeichen beglückt. Argumente haben dort übrigens auch nichts gebracht - so als Hinweis am Rande. Ansonsten kann ich zum Thema nur sagen, dass ich die Vorlage absolut unsinnig finde. Nicht nur, dass es recht dämlich aussieht, wenn im Artikel ein halbes Bild zu sehen ist, wo man per Scrollbalken zum Rest scrollen muss, sondern barrierefrei ist es auch nicht. Zudem stellen die Bilder im Artikel in aller Regel eh nur eine verkleinerte Vorschau da, die Detailversion gibts per Klick darauf. Und in aller Regel möchte ich ein Bild auf einem Blick sehen ohne scrollen. Sonst können wir auch hingehen und die üblichen Bilder in überdimensional und mit Scrollbalken versehen einbinden. --STBR – !? 15:49, 14. Sep. 2009 (CEST)
- (BK) DaSch: Tatsache 1: Die Vorlage bindet einen Scrollbalken ein. Tatsache 2: Scrollbalken stellen für Menschen mit bestimmten Behinderungen eine Barriere dar. Tatsache 3: Bilder mit entsprechender Größe lassen sich ohne diese Vorlage quasi gleich groß in Artikeln darstellen. Tatsache 4: selbst der Programmierer dieser Vorlage zeigt mehr Einsicht als Du. – Wladyslaw [Disk.] 15:51, 14. Sep. 2009 (CEST)
- Um das endgültig zu klären werde ich ein MB starten an dem ihr euch alle gerne beteiligen dürft. Ich hoffe das wird helfen den Umgang mit dieser Vorlage endgültig zu klären. --DaSch/Feuerwehrkontrolle 15:53, 14. Sep. 2009 (CEST)
- Stell am besten gleich noch ein Meinungsbild, ob der Mittwoch wirklich vor dem Donnerstag kommt. – Wladyslaw [Disk.] 15:55, 14. Sep. 2009 (CEST)
- Hüstel... Seit wann sind denn Scrollbalken nicht Barrierefrei? Jeder Texteditor, jede Seite hat sie und sie können vollständig, allein durch Tastatur, Maus, Gamepad (PS3), etc. bedient werden. Ich persönlich finde die Vorlage sogar besser, als in fester größe eingebundene Bilder, die bei schmalen Displays sogar überstehen und dann erst recht Scrollbalken erzeugen. -- 16:13, 14. Sep. 2009 (CEST)
- Stell am besten gleich noch ein Meinungsbild, ob der Mittwoch wirklich vor dem Donnerstag kommt. – Wladyslaw [Disk.] 15:55, 14. Sep. 2009 (CEST)
Vertikal Scrollbalken sind durch die Artikellänge natürlich. Kommt dazu noch ein horizontaler dazu, dann ist das Choas perfekt und man braucht (wenn man keine Maus nutzen kann aufgrund einer Behinderung) kryptische und nicht immer funktionierende Tastenkombinationen für die Bedingung.
Dazu: fest eingebundene Bilder überragen bei korrekter Einbindung nie den Rand, die Vorlage hingegen praktisch jedes Mal. – Wladyslaw [Disk.] 16:17, 14. Sep. 2009 (CEST)
- Es geht um unnötige Scrollbalken. Ja bitte, wir hatten lange kein MB mehr. --Marcela 16:19, 14. Sep. 2009 (CEST)
- Schon mal darüber nachgedacht, dass besonders viele behinderte Menschen sowieso die Schrift und Bildgröße drastisch erhöhen um etwas erkennen zu können? Da sind vertikale Scrollbalken ganz häufig anzutreffen. Hier taucht dann nur ein Scrollbalken innerhalb der Seite auf, der nicht weiter relevant ist, wenn der Nutzer nicht das gesamte Bild sehen möchte. Dafür hätten wir bei der statischen Lösung ein Bild was über die Seitenbreite hinausgeht und dann einen Scrollbalken erzwingt. Das ist auch nicht besser und im allgemeinen sogar schlechter, da noch verwirrender. -- 16:28, 14. Sep. 2009 (CEST)
- Mupitz: bei der Vergrößerung der Schrift taucht in der Wikipedia kein horizontaler Scrollbalken auf. Außerdem ist es ein Unterschied ob auf einer Seite sowohl horizontale wie vertikale Scrollbalken existieren oder ob in einer Seite mit vertikalem Scrollbalken ein eigenes Fenster mit horizontalem enthalten ist. Zudem ist kein Mehrwert für die Artikel mit der Vorlage verbunden. – Wladyslaw [Disk.] 16:31, 14. Sep. 2009 (CEST)
- Doch tut es. Such dir eine Seite mit einer Tabelle aus und vergrößere die Schrift; je horizotal dichter die Tabelle desto eher. Es stimmt auch nicht das die Vorlage nicht barrierefrei sei, weil der Scrollbalken im Text nicht mit Tastatur zu bedienen wäre. --Mps 16:52, 14. Sep. 2009 (CEST)
- Wie ich bereits sagte: mit kryptischen Shortcuts, die zudem nicht immer funktionieren (browserabhängig) ist diese zu bedienen. – Wladyslaw [Disk.] 16:56, 14. Sep. 2009 (CEST)
- Wer mit den Shortcuts nicht umzugehen weiß, der "klickt" einfach auf das Bild und schaut es sich in voller Größe an. Das muss er bei diesen kleinen Vorschaubildchen dann ja ohnehin machen, da man darauf nichts erkennen kann. -- 17:03, 14. Sep. 2009 (CEST)
- Mit dem Unterschied, dass er im einen Fall gezwungen wird, dies zu tun, im anderen Fall nicht. Es gibt immer noch kein stichhaltiges Argument, für den Mehrwert dieser Vorlage. Die Miniaturansicht verfolgt den Zweck, das ganze (!) Bild kurz zu zeigen. Wer es anschauen will, klickt es an, wer nicht der lässt es bleiben. Diese Vorlage drängt das Bild unnötiger Weise in den Fokus der Aufmerksamkeit. – Wladyslaw [Disk.] 17:07, 14. Sep. 2009 (CEST)
- Er ist in keinem der beiden Fällen gezwungen etwas zu tun. Das obliegt dem Nutzer und ist daher eine falsche Feststellung/Darstellung deinerseits. Die Vorlage verfolgt hingegen das Ziel, das gesamte Bild darzustellen, ohne das es in irgendeinem Fall zu einer Einblendung der Seiten-Scrollleiste kommt. Das ist durchaus lobenswert und auch genau der Gedanke hinter der CSS-Option "overflow". PS: Keine Ahnung wie auffällig deine Scrollleisten sind, bei mir wirken sie aber recht neutral. -- 17:27, 14. Sep. 2009 (CEST)
- Bei mir nicht. Ich warte auf stichhaltige Argumente. – Wladyslaw [Disk.] 17:28, 14. Sep. 2009 (CEST)
- Hier mal ein paar, da es ja sowieso nicht viele geben könnte:
- Das Bild kann auch in der Vorschau größer (höher) dargestellt werden, was vielen Lesern bereits als Überblick reichen sollte und für diese auch noch gut erkenntlicht ist
- Bei stark vergrößerter Seitendarstellung taucht keine weitere horizontale Scrollleiste auf, da die Vorlage mit der Seite skaliert
- Die Bedienung der Scrollleisten ist vergleichbar einfach bei der Navigation und weitgehend gut gelöst. Sowohl beim IE als auch beim FF. (Kein Unterschied zwischen Leiste im Bild oder am Browserfensterrand)
- Punkt 1 und 2 schließen zusammen lange Schaulbilder aus, die nur als Thumb eingebunden sind, da sie entweder für alle zu klein sind oder eben noch eine zusätzliche Scrollleiste auftaucht.
- Daraus folgt auch, dass die Vorlagenlösung konsistenter ist.
- -- 17:42, 14. Sep. 2009 (CEST)
- Hier mal ein paar, da es ja sowieso nicht viele geben könnte:
- Bei mir nicht. Ich warte auf stichhaltige Argumente. – Wladyslaw [Disk.] 17:28, 14. Sep. 2009 (CEST)
- Er ist in keinem der beiden Fällen gezwungen etwas zu tun. Das obliegt dem Nutzer und ist daher eine falsche Feststellung/Darstellung deinerseits. Die Vorlage verfolgt hingegen das Ziel, das gesamte Bild darzustellen, ohne das es in irgendeinem Fall zu einer Einblendung der Seiten-Scrollleiste kommt. Das ist durchaus lobenswert und auch genau der Gedanke hinter der CSS-Option "overflow". PS: Keine Ahnung wie auffällig deine Scrollleisten sind, bei mir wirken sie aber recht neutral. -- 17:27, 14. Sep. 2009 (CEST)
- Mit dem Unterschied, dass er im einen Fall gezwungen wird, dies zu tun, im anderen Fall nicht. Es gibt immer noch kein stichhaltiges Argument, für den Mehrwert dieser Vorlage. Die Miniaturansicht verfolgt den Zweck, das ganze (!) Bild kurz zu zeigen. Wer es anschauen will, klickt es an, wer nicht der lässt es bleiben. Diese Vorlage drängt das Bild unnötiger Weise in den Fokus der Aufmerksamkeit. – Wladyslaw [Disk.] 17:07, 14. Sep. 2009 (CEST)
- Wer mit den Shortcuts nicht umzugehen weiß, der "klickt" einfach auf das Bild und schaut es sich in voller Größe an. Das muss er bei diesen kleinen Vorschaubildchen dann ja ohnehin machen, da man darauf nichts erkennen kann. -- 17:03, 14. Sep. 2009 (CEST)
- Wie ich bereits sagte: mit kryptischen Shortcuts, die zudem nicht immer funktionieren (browserabhängig) ist diese zu bedienen. – Wladyslaw [Disk.] 16:56, 14. Sep. 2009 (CEST)
- Doch tut es. Such dir eine Seite mit einer Tabelle aus und vergrößere die Schrift; je horizotal dichter die Tabelle desto eher. Es stimmt auch nicht das die Vorlage nicht barrierefrei sei, weil der Scrollbalken im Text nicht mit Tastatur zu bedienen wäre. --Mps 16:52, 14. Sep. 2009 (CEST)
- Mupitz: bei der Vergrößerung der Schrift taucht in der Wikipedia kein horizontaler Scrollbalken auf. Außerdem ist es ein Unterschied ob auf einer Seite sowohl horizontale wie vertikale Scrollbalken existieren oder ob in einer Seite mit vertikalem Scrollbalken ein eigenes Fenster mit horizontalem enthalten ist. Zudem ist kein Mehrwert für die Artikel mit der Vorlage verbunden. – Wladyslaw [Disk.] 16:31, 14. Sep. 2009 (CEST)
- Schon mal darüber nachgedacht, dass besonders viele behinderte Menschen sowieso die Schrift und Bildgröße drastisch erhöhen um etwas erkennen zu können? Da sind vertikale Scrollbalken ganz häufig anzutreffen. Hier taucht dann nur ein Scrollbalken innerhalb der Seite auf, der nicht weiter relevant ist, wenn der Nutzer nicht das gesamte Bild sehen möchte. Dafür hätten wir bei der statischen Lösung ein Bild was über die Seitenbreite hinausgeht und dann einen Scrollbalken erzwingt. Das ist auch nicht besser und im allgemeinen sogar schlechter, da noch verwirrender. -- 16:28, 14. Sep. 2009 (CEST)
- Das Bild kann auch in der Vorschau größer (höher) dargestellt werden, was vielen Lesern bereits als Überblick reichen sollte und für diese auch noch gut erkenntlicht ist.
- Und genau das ist nicht erwünscht. Wir schreiben eine bebilderte Enzyklopädie und kein Bildband mit enzyklopädischem Text. Wie ich bereits sagte, rückt sich damit das Bild zu stark in den Fokus der Aufmerksamkeit.
- Das Bild kann auch in der Vorschau größer (höher) dargestellt werden, was vielen Lesern bereits als Überblick reichen sollte und für diese auch noch gut erkenntlicht ist.
- Bei stark vergrößerter Seitendarstellung taucht keine weitere horizontale Scrollleiste auf, da die Vorlage mit der Seite skaliert
- Bei relativen Größenangaben scrollt die Darstellung ebenfalls in Abhängigkeit von der Seitengröße.
- Bei stark vergrößerter Seitendarstellung taucht keine weitere horizontale Scrollleiste auf, da die Vorlage mit der Seite skaliert
- Die Bedienung der Scrollleisten ist vergleichbar einfach bei der Navigation und weitgehend gut gelöst. Sowohl beim IE als auch beim FF. (Kein Unterschied zwischen Leiste im Bild oder am Browserfensterrand)
- Wie bereits beschrieben ist das eben doch ein Problem, was es zur nicht barrierefreien Vorlage macht. Aus genannten Gründen folgt, dass die Vorlage zu vermeiden ist. Einzelfälle mag ich tollerien und es gibt Beispiele für sehr extreme Bildgrößenverhältnisse, wo ich den Einsatz der Vorlage trotz seiner Nachteile für in Ordnung befinde. Für „gewöhnliche“ Panoramas mit entsprechendem Verhältnis von Höhe und Breite sind sie nicht nur verzichtbar sondern verschandeln auch noch den Artikel. – Wladyslaw [Disk.] 17:48, 14. Sep. 2009 (CEST)
- Die Bedienung der Scrollleisten ist vergleichbar einfach bei der Navigation und weitgehend gut gelöst. Sowohl beim IE als auch beim FF. (Kein Unterschied zwischen Leiste im Bild oder am Browserfensterrand)
- "Und genau das ist nicht erwünscht. ..." Das ist doch Unsinn, wenn man Bilder verbaut die so klein sind, dass man nichts mehr erkennt, aber auf der anderen Seite bei Bildern (nicht höher als ein Thumb) moniert, dass WP kein Bilderband ist. Wenn dem so ist, dann sollte man die Bilder aus dem Artikel entfernen und auf Commons verlinken. Dann ist das Problem gleich gelöst.
- "Bei relativen Größenangaben scrollt die Darstellung ebenfalls in Abhängigkeit von der Seitengröße." Stimmt nicht, da die relative Größe nichts mit der letzlichen Darstellung bei der Vergrößerung durch den Browser zu tun hat. Zudem frage ich mich dann, warum diese nicht verwendet werden?
- "Wie bereits beschrieben ist das eben doch ein Problem, was es zur nicht barrierefreien Vorlage macht." Das müsstest du jetzt erst einmal beweisen. Ich behaupte das Gegenteil. ;-) -- 17:59, 14. Sep. 2009 (CEST)
- Der Größenunterschied zwischen der Einbindung mit der Vorlage und der regulären Einbindung ist in vielen Fällen marginal. Abgesehen davon: eine Miniaturansicht ist eine Miniaturansicht und soll auch eine bleiben. Es ist nicht Ziel eines Artikels Panoramen hochauflösend und groß darzustellen. Derjenige, der das Panorma mit allen Einzelheiten anschauen will wird es auch in der Vorlageneinbindung anklicken müssen.
- Barrierefreiheit: mir selbst gelingt es nicht, mit irgendwelchen Tastaturbefehlen die horizontalen Scrollbalken zu verschieben. Welche Tastten muss man dafür bemühen? – Wladyslaw [Disk.] 18:05, 14. Sep. 2009 (CEST)
- Einfach mit der Tab-Taste bis zum entsprechenden Element navigieren und dann einfach die Pfeiltasten zum scrollen verwenden. Mehr ist das nicht. -- 18:24, 14. Sep. 2009 (CEST)
- Tja, funktioniert nicht. Wunderbar. – Wladyslaw [Disk.] 09:28, 15. Sep. 2009 (CEST)
- Dann machst du da was falsch. Das funktioniert bereits seit Firefox 2.0 genau so, wie ich es beschreiben habe und das sowohl unter Windows, Linux und Mac. Wie es der IE nun handhabt kann ich nicht genau sagen. In meinen Augen ist das aber sowieso die größte Krücke. -- 09:38, 15. Sep. 2009 (CEST)
- Tja, funktioniert nicht. Wunderbar. – Wladyslaw [Disk.] 09:28, 15. Sep. 2009 (CEST)
- Einfach mit der Tab-Taste bis zum entsprechenden Element navigieren und dann einfach die Pfeiltasten zum scrollen verwenden. Mehr ist das nicht. -- 18:24, 14. Sep. 2009 (CEST)
- Hier geht's weiter → Wikipedia:Meinungsbilder/Verwendung von Panoramabildern --DaSch/Feuerwehrkontrolle 16:33, 14. Sep. 2009 (CEST)
- Nö, hier und hier und hier und hier. Erst BITV lesen, dann diskutieren. --Marcela 16:42, 14. Sep. 2009 (CEST)
- Kannst du mir mal die stellen raussuchen, an der geschrieben steht, dass einfache horizontale Scrollbalken schlecht wären, wenn das Bild sowieso nicht auf die Seite passen würde? -- 16:48, 14. Sep. 2009 (CEST)
- Es kommt nicht ausschließlich auf eine Stelle oder eine Bemerkung an. Für Screenreader ist eine übergroße Bilddarstellung ein eingebettetes Objekt, welches beschrieben wird. Ein Bild mit Scroll-Balken hingegen wird als eingebettetes Objekt betrachtet, um den Inhalt zu erfahren, muß dieses Objekt besuchte werden. Gleiches gilt vergleichsweise für Tastatur-Bedienung, der gesamte Browserinhalt ist sehr leicht verschiebbar, ein einzelnes Objekt ist schwer zu erwischen. Es geht nicht nur um Blinde, nur um Tastatur-Bedienung. Es geht auch um Menschen mit motorischen Störungen oder anderwertig Behinderte. Dazu ist eine einzelne Textpassage nicht ausreichend, man muß das gesamte Umfeld betrachten. Meine Studenten hatten ein halbes jahr Zeit, sich einzeln zu ganz bestimmten Aspekten Gedanken zu machen. Sowas ist nicht "mal schnell" erklärt: http://de.wikiversity.org/wiki/Kurs:Barrierefreiheit_von_Internetseiten --Marcela 17:43, 14. Sep. 2009 (CEST)
- Da dürftest du in diesem Falle falsch liegen. Denn da das Bild hier mit einem einfachen "overflow-Attribut" versehen ist, wird es ganz normal wie jedes andere Bild behandelt, bzw. sollte es dies. Für das was du meinst sind die Tags iframe und object gedacht. Reine DIV-Container sollten innerhalb der Darstellung eines Screenreaders nicht beachtet werden, da diese keine Funktion für den Dokumenteninhalt erfüllen. -- 17:52, 14. Sep. 2009 (CEST)
- Kann durchaus sein. JAWS sieht das aber anders. Und das ist die weltweit am meisten verbreitete Screenreader-Software. Wer da nun den schwarzen Peter hat, kann ich nicht einschätzen, es wird aber unnötigerweise eine barriere aufgebaut. --Marcela 18:09, 14. Sep. 2009 (CEST)
- Sehr merkwürdig? Welche Version soll das denn sein? Bei mir macht das selbst Orca richtig und dabei hat das Ding durchaus seine Macken. -- 18:32, 14. Sep. 2009 (CEST)
- Fehlerhaft ist es in 7 und 10 unter FF 3.5, 8 und 9 machen es korrekt. In Opera mit 10 korrekt, im IE geht alles erfahrungsgemäß ordentlich. Screenreader-Benutzer sind daran gewöhnt, sie haben immer mehrere JAWS am laufen und greifen sich den, bei dem sie das meiste ordentlich "sehen" können. Es gibt mit allen Screenreadern Probleme, alle sind fehlerhaft, das ist bekannt. Hier halte ich es aber für falsch, aufs W3C zu verweisen, das nutzt den Menschen mit Behinderungen wenig. Man sollte ihnen die Inhalte möglichst einfach präsentieren. Selbst wenn W3C und Standards das anders sehen, wir müssen mit den Realitäten leben. --Marcela 18:40, 14. Sep. 2009 (CEST)
- Da hast du schon recht, nur gehe ich hier davon aus, dass es kein besonderes Hindernis ist, das zudem recht selten und höchstens ein mal pro Artikel aufzutreten scheint. Im Gegenzug können die anderen Leser auch noch was auf den Bildern erkennen und müssen nicht noch zweimal klicken um das Bild in einer akzeptablen Auflösung sehen zu können. Das spart in diesem Fall sogar auch noch Resourcen. ;-) -- 18:50, 14. Sep. 2009 (CEST)
- Ich denke, optimal bekommen wir das niemals für alle Nutzer hin. Und wenn wir scheinbar die Hürden für Behinderte beseitigt haben, haben wir wieder Hürden für Normalos eingebaut. Ich war bei allen BIENE-Verleihungen, da wurde im Laufe der Zeit klar, daß es keine Barrierefreiheit geben wird (das sah man zur ersten BIENE 2003 noch anders). Neben gegenseitigem bauchpinseln sind die Veranstaltungen sehr interessant, weil man mit vielen betroffenen Menschen reden kann. Dabei stellt sich immer wieder raus, daß man als Unwissender Barrieren an Stellen vermutet, die keine sind und daß scheinbare Kleinigkeiten echte Barrieren sein können. Sowas gehört nicht hier auf die Disk sondern ins Biene-projekt, ich bin auch nicht allwissend und lerne ständig dazu. Lalü und Lecartia sind in unserem Projekt da wohl am ehesten aussagefähig. --Marcela 19:15, 14. Sep. 2009 (CEST)
- Sehr merkwürdig? Welche Version soll das denn sein? Bei mir macht das selbst Orca richtig und dabei hat das Ding durchaus seine Macken. -- 18:32, 14. Sep. 2009 (CEST)
- Kann durchaus sein. JAWS sieht das aber anders. Und das ist die weltweit am meisten verbreitete Screenreader-Software. Wer da nun den schwarzen Peter hat, kann ich nicht einschätzen, es wird aber unnötigerweise eine barriere aufgebaut. --Marcela 18:09, 14. Sep. 2009 (CEST)
- Da dürftest du in diesem Falle falsch liegen. Denn da das Bild hier mit einem einfachen "overflow-Attribut" versehen ist, wird es ganz normal wie jedes andere Bild behandelt, bzw. sollte es dies. Für das was du meinst sind die Tags iframe und object gedacht. Reine DIV-Container sollten innerhalb der Darstellung eines Screenreaders nicht beachtet werden, da diese keine Funktion für den Dokumenteninhalt erfüllen. -- 17:52, 14. Sep. 2009 (CEST)
- Es kommt nicht ausschließlich auf eine Stelle oder eine Bemerkung an. Für Screenreader ist eine übergroße Bilddarstellung ein eingebettetes Objekt, welches beschrieben wird. Ein Bild mit Scroll-Balken hingegen wird als eingebettetes Objekt betrachtet, um den Inhalt zu erfahren, muß dieses Objekt besuchte werden. Gleiches gilt vergleichsweise für Tastatur-Bedienung, der gesamte Browserinhalt ist sehr leicht verschiebbar, ein einzelnes Objekt ist schwer zu erwischen. Es geht nicht nur um Blinde, nur um Tastatur-Bedienung. Es geht auch um Menschen mit motorischen Störungen oder anderwertig Behinderte. Dazu ist eine einzelne Textpassage nicht ausreichend, man muß das gesamte Umfeld betrachten. Meine Studenten hatten ein halbes jahr Zeit, sich einzeln zu ganz bestimmten Aspekten Gedanken zu machen. Sowas ist nicht "mal schnell" erklärt: http://de.wikiversity.org/wiki/Kurs:Barrierefreiheit_von_Internetseiten --Marcela 17:43, 14. Sep. 2009 (CEST)
- Kannst du mir mal die stellen raussuchen, an der geschrieben steht, dass einfache horizontale Scrollbalken schlecht wären, wenn das Bild sowieso nicht auf die Seite passen würde? -- 16:48, 14. Sep. 2009 (CEST)
- <------------
- Zu einem zufällig entdeckten, knuffigen Effekt habe ich hier mal eine Frage gestellt. -- smial 00:53, 25. Sep. 2009 (CEST)
Noch etwas von mir
Ich halte dafür ein MB nicht geeignet, deshalb diskutiere ich hier eben noch eine Runde weiter. ;-) Also du meinst ja, dass die "Mupitz" ist. Deshalb habe ich hier mal ganz trivial zwei Screenshots gemacht. [17] [18] [19]
Auf diesen sollte man recht deutlich erkennen, dass es eben auch keine ideale Lösung ist. Da 1. die Bilder dadurch zu klein werden, als das man noch was erkennen könnte und 2. trotzdem diese Scrollbalken immer wieder auftauchen. Ich kann hier beim besten Willen nicht den Nachteil gegenüber dieser Vorlage erkennen. -- 16:45, 14. Sep. 2009 (CEST)
Meinungsbild
→ Wikipedia:Meinungsbilder/Verwendung von Panoramabildern Zum Thema Meinungsbild. Da wir hier rein argumentativ keinen Konsens finden werden halt ich es für notwendig die Positionen klar darzustellen und einem breiten Publikum zu präsentieren. Dann kann die Community entscheiden ob die Einwände stichhaltig und nachvollziehbar sind oder die Vorteile der Vorlage den Bedenken überwiegen. --DaSch/Feuerwehrkontrolle 16:50, 14. Sep. 2009 (CEST)
Hochgeladene neue Dateienversion wird nicht immer angezeigt
Ich habe bei Commons eine neue Version von Datei:Sucos Ainaro.png hochgeladen und sie dann auch in Wikipedia:Kartenwerkstatt eingebunden. Dort wird sie korrekt angezeigt. Nicht jedoch bei den Artikeln, in denen sie zuvor schon eingebunden war, wie z.B. Ainaro. Dort wird immer noch die alte Version angezeigt. Cache löschen hilft nichts, an einem anderen Anschluß und Computer zeigt sich das selbe Bild und "?action=purge" hat nur bewirkt, dass das Bildfenster die Umrisse der neuen Datei hat, innen aber das alte Bild verzerrt gezeigt wird. Ein Versuch mit einem "Nulledit" bei Maubisse hat auch keine Änderung gebracht. Bei Wikipedia:Fragen zur Wikipedia bekam ich leider keine weitere Vorschläge. --JPF ''just another user'' 17:02, 25. Sep. 2009 (CEST)
- Bei mir wird es richtig angezeigt. Es kann daran liegen, dass ich eine andere Standardbildbreite habe, also Du. Bei Dir wird wahrscheinlich ein altes Bild aus dem Cache geladen. Ich habe mal mit http://commons.wikimedia.org/w/index.php?title=File:Sucos_Ainaro.png&action=purge gepurged. Besteht das Problem immer noch? --Fomafix 17:34, 25. Sep. 2009 (CEST)
- Ja. Ich hatte bereits auf meinen PC das Cache gelöscht, an einem anderen Anschluss/PC das selbe Ergebnis und den Befehl purge hatte ich auch schon probiert. Erst wenn ich den Artikel umbaue (z.B. Ainaro (Distrikt)) ändert sich das Bild, was aber nicht durchweg als Lösung funktionieren kann. --JPF ''just another user'' 22:22, 25. Sep. 2009 (CEST)
- Welche Breite in Pixel hat bei Dir das Bild? --Fomafix 00:23, 26. Sep. 2009 (CEST)
- Du meinst das falsch angezeigte Bild im Artikel? 180px × 345px (skaliert auf 180px × 264px). Nach grundlegenden Überarbeitung wird es noch falsch angezeigt in den Artikeln: Hato-Udo, Hatu-Builico und Liste der Verwaltungseinheiten Osttimors --JPF ''just another user'' 13:30, 26. Sep. 2009 (CEST)
- Ich kann keine Probleme feststellen. Weder am linken noch am rechten Bild. Beide sind aktuell und zeigen http://upload.wikimedia.org/wikipedia/commons/3/3a/Sucos_Ainaro.png an. --Fomafix 10:31, 27. Sep. 2009 (CEST)
- Woran es auch immer liegt. Heute werden erstmals die VErsionen richtig angezeigt. Problem nicht mehr existent. Danke. --JPF ''just another user'' 13:37, 27. Sep. 2009 (CEST)
- Ich kann keine Probleme feststellen. Weder am linken noch am rechten Bild. Beide sind aktuell und zeigen http://upload.wikimedia.org/wikipedia/commons/3/3a/Sucos_Ainaro.png an. --Fomafix 10:31, 27. Sep. 2009 (CEST)
- Du meinst das falsch angezeigte Bild im Artikel? 180px × 345px (skaliert auf 180px × 264px). Nach grundlegenden Überarbeitung wird es noch falsch angezeigt in den Artikeln: Hato-Udo, Hatu-Builico und Liste der Verwaltungseinheiten Osttimors --JPF ''just another user'' 13:30, 26. Sep. 2009 (CEST)
- Welche Breite in Pixel hat bei Dir das Bild? --Fomafix 00:23, 26. Sep. 2009 (CEST)
- Ja. Ich hatte bereits auf meinen PC das Cache gelöscht, an einem anderen Anschluss/PC das selbe Ergebnis und den Befehl purge hatte ich auch schon probiert. Erst wenn ich den Artikel umbaue (z.B. Ainaro (Distrikt)) ändert sich das Bild, was aber nicht durchweg als Lösung funktionieren kann. --JPF ''just another user'' 22:22, 25. Sep. 2009 (CEST)
Bilder einbinden
(Die nachfolgenden sechs Beiträge wurde nachträglich von Benutzer Diskussion:Konrad F.#Bilddateien hier her geschoben.)
Wenn ich es richtig sehe hast du z.B. im Artikel Fachwerk die Bilddateien von Datei: in Bild: umbenannt. Das ist bei WP nicht gewünscht. Bilddateien sollen immer mit Datei: bezeichnet werden. Siehe hier Hilfe:Bilder#Einbindung. Vielleicht hast du das übersehen. -- Petflo2000 20:01, 26. Sep. 2009 (CEST)
- Nein, das (Zitat: „.. sind Artikelbearbeitungen, die ausschließlich derartige Änderungen vornehmen, wegen der unnötigen Serverbelastung nicht erwünscht.“) habe ich nicht übersehen (früher war das übrigens mal
"File"
und"Image"
, aber im Sinne der Deutschen WP wurde das angenehmer Weise irgendwann mal übersetzt). Und soweit ich das zuletzt gesehen habe, ist die Einbindung mit"Datei"
immernoch eine Kann- und keine Muß-Bestimmung. Wenn einige Leute der (für mich nicht nachvollziehbaren) Meinung sind, daß die Einbindung mit"Bild"
(für Bilder) veraltet ist, dann ist das deren gutes Recht. Das aber so in die Richtlinien aufzunehmen, ohne dafür einen guten Grund zu geben, finde ich jedoch so nicht in Ordnung. Ich finde"Datei"
jedenfalls zu allgemein (und länger ist es auch), vor allem auch im Sinne der besseren Lesbarkeit des Quelltextes ist meiner Meinung nach daher"Bild"
sogar vorzuziehen (siehe dazu auch Audio und Video).[20] - --Konrad – 07:17, 27. Sep. 2009 (CEST)
Ich finde, dass eine einheitliche Bezeichnung sinnvoller ist. Und da dieser Vorschlag von WMF (Wikimedia Foundation) vereinbart wurde, würde ich bei der neuen Bezeichnung bleiben. Mir sind auch keine wesentlichen Diskussionen bei WP bekannt, wo dies auf Widerstand gestossen ist. Übrigens, wenn man in einem Artikel ein Bild anklickt/-wählt wird immer die Bezeichnung Datei statt Bild angezeigt. Wenn du meinst bei Bild bleiben zu müssen ist das vielleicht für deine Beiträge OK. Aber bitte ändere keine bestehenden Artikel dahingehend ab. Wenn hier jeder sein eigenes Süppchen kocht kann man WP gleich vergessen. Man muss sich auch manchmal auch einer Mehrheit anschließen. Ansonsten sollte man das Thema in einer größeren Runde diskutieren um zu einem einvernehmlichen Konsens zu kommen. -- Petflo2000 20:01, 29. Sep. 2009 (CEST)
- Zitat: „Man muss sich auch manchmal [..] einer Mehrheit anschließen.“ Dem stimme ich zu, allerdings muß es auch tatsächlich eine Mehrheit und – was gerade hier in der WP noch viel wichtiger ist (siehe dazu auch WP:NNAAT) – nachvollziehbare Gründe dafür geben. Jedoch ist keines von beiden (in diesem Fall hier) – sogar nach deiner eigenen Aussage (Zitat: „Mir sind auch keine wesentlichen Diskussionen bei WP bekannt, ..“) – bisher erkennbar.
- Das (Zitat: „Ansonsten sollte man das Thema in einer größeren Runde diskutieren ..“) sehe ich auch so. Also wo meinst du, ist denn ein besserer Ort, um hierzu einen einvernehmlichen Konsens zu erreichen oder zu finden (falls dieser schon existiert)?
- --Konrad – 12:29, 30. Sep. 2009 (CEST)
Ich glaube kaum, dass du mit deiner Ansicht in einer Diskussion durchkommst, da es sich hierbei um eine Grundsatzentscheidung der WMF (Wikimedia Foundation) und damit auch international festgelegt wurde. Aber du kannst ja mal eine entsprechende Grundsatzdiskussion anzuregen, vor allem wenn du weiterhin deine Bezeichnungen verwenden willst. Mir persönlich wäre es im Prinzip egal, aber solange die Regeln so sind halte ich mich daran. -- Petflo2000 20:08, 2. Okt. 2009 (CEST) PS: Wenn du eine Diskussion anregst, gib mir bitte Bescheid wo, würde mich interessieren.
- na, es ist doch ganz einfach: wenn man einen neuen artikel schreibt, dann macht man es so, wie es einem am ehesten passt. bearbeitet man "fremde" artikel oder nimmt sonst kaum nennenswerte änderungen vor, so lässt man auch die finger vom stand der dinge in sachen formatierung. insbesondere, wenn die eigenen vorlieben offensichtlich nicht breiter konsens ist. --JD {æ} 21:40, 2. Okt. 2009 (CEST)
Entschuldigt bitte, aber das wird mir jetzt zu viel. Wenn ihr die Richtlinien im Sinne von Gesetzten interpretieren wollt, dann laßt das bitte nicht an mir aus. Ich finde jedoch, es sollte auch ein gewisses Maß an Freiheit möglich sein. Im Übrigen finde ich es auch wesentlich sinnvoller, Artikel zu schreiben, als sich hier um irgendwelche Paragrafen zu streiten.
--Konrad – 12:22, 3. Okt. 2009 (CEST)
- Konrad F.: Also, deine Aufregung kann ich nicht verstehen. Du änderst andere Beiträge hier z.B. [21] entgegen der Richtlinien und wunderst dich wenn man dich dafür kritisiert. Dann lass doch solche unnötigen Änderungen und halte dich an deine eigene Empfehlung lieber Artikel zu schreiben. Ich hatte auch eigentlich den Eindruck, dass du mit der Verschiebung hierher eine Grundsatzdiskussion anregen wolltest, ob für eingebundene Bilddateien die Bezeichnung Datei:xyz, wie von WMF (Wikimedia Foundation) empfohlen, oder Bilde:xyz, wie früher einmal, sinnvoller ist. Denn mal los mit der Diskussion! -- Petflo2000 20:41, 5. Okt. 2009 (CEST)
Diverse Fragen
Ein Bekannter von mir wollte in nächster Zeit ein paar Bilder für WP machen. Er selber hat keinen Account hier (und möchte auch keinen), deswegen wollte ich die für ihn hochladen. Was genau ist dabei zu beachten? Macht es einen Unterschied, ob die Bilder hier oder bei Commons hochgeladen werden (ich würd sie hier auf de hochladen, weil ich eigentlich keinen zusätzlichen account für commoms machen wollte)? Was ist bei der Lizensierung bzw. dem Urheberrecht zu beachten? Er will sie unter die Creative Commons Lizenz Stellen. Gibt es eine Möglichkeit, dass er mir für alle seine Bilder vorab das Upload-Recht erteilt (so, dass wir nicht für jedes Bild eine Extraerlaubnis verfassen müssen)? Also quasi so, dass ich für jedes neue Bild, dass er gerne beisteuern möchte, nur noch auf die Erlaubnis verweisen, ihn als Urheber eintragen und das Bild hochladen muss. Und gibt es sonst noch irgendwas zu beachten? --maststef 12:26, 2. Okt. 2009 (CEST)
- Bitte beachten den Hinweis am Seitenanfang. WP:UF scheint ein besserer Anlaufpunkt zu sein. Mit WP:SUL wären Benutzerkonten auf anderen Projekten unproblematisch. Der Umherirrende 18:14, 5. Okt. 2009 (CEST)
- Finger weg von solchen Konstruktionen. Entweder er will die Bilder wirklich unter einer Creative-Commons-Lizenz freigeben (welche?), dann dürfte es kein Problem für ihn sein, sich fürs Hochladen einen Account anzulegen, oder eben nicht, dann bitte auch nicht mit dubiosen mündlichen Absprachen, die jederzeit geleugnet werden können. Die ganze Situation zeigt, dass er sich unsicher ist und dass er sich in die Unverbindlichkeit einer mündlichen Absprache flüchten möchte; er sollte überlegen, ob er die Konsequenzen der CC-Lizenz, die er ausgewählt hat, wirklich versteht und wirklich tragen kann. --rtc 20:46, 5. Okt. 2009 (CEST)
- Über die Lizenz (CC-by-sa 3.0) ist er aufgeklärt, unsicher ist er nicht, er will halt nur keinen Account, deswegen hab ich es ihm angeboten, das hochladen zu übernehmen (falls es lizenztechnisch möglich ist, was ich hier gerade versuche, herauszufinden). Dann wird's wohl aber keine Bilder geben, so wie es aussieht. Trotzdem danke für die Auskunft. --maststef 21:46, 5. Okt. 2009 (CEST)
- Warum "will [er] halt nur keinen Account"? Das sollte doch nun wirklich kein Problem, mit zwei, drei Klicks sich einen Account einzurichten und Bilder hochzuladen. --rtc 23:05, 5. Okt. 2009 (CEST)
- Wird das jetzt ein Verhör? Ich habe lediglich gefragt, ob das irgendwie möglich ist. Selbst ohne den speziellen Fall hier kann ich viele allgemeine Gründe nennen, warum sich jemand nicht anmelden will (und wenn danach keine Antworten kommen, die sich endlich mal mit meiner Frage befassen, ist das Thema für mich beendet): keine Zeit, keine Zeit/Lust sich in die WP-Internas einzuarbeiten, keine großes eigenes Interesse an der WP (aber Interesse an Verebreitung des Wissens/der Bilder unter einen freien Lizenz), uvm... --maststef 08:44, 6. Okt. 2009 (CEST)
- Warum "will [er] halt nur keinen Account"? Das sollte doch nun wirklich kein Problem, mit zwei, drei Klicks sich einen Account einzurichten und Bilder hochzuladen. --rtc 23:05, 5. Okt. 2009 (CEST)
- Über die Lizenz (CC-by-sa 3.0) ist er aufgeklärt, unsicher ist er nicht, er will halt nur keinen Account, deswegen hab ich es ihm angeboten, das hochladen zu übernehmen (falls es lizenztechnisch möglich ist, was ich hier gerade versuche, herauszufinden). Dann wird's wohl aber keine Bilder geben, so wie es aussieht. Trotzdem danke für die Auskunft. --maststef 21:46, 5. Okt. 2009 (CEST)
- Weshalb hier nun wieder der Ton eskaliert, weiß ich nicht. Es hätte auch ganz einfach sein können, denn genau für diese Frage haben wir seit langem einen passenden Weg. -- smial 12:09, 6. Okt. 2009 (CEST) der im Moment mit einem älteren Herrn im Gespräch ist, der ganz gewiß keinen WP-Account will, da ihm das alles viel zu kompliziert ist, der aber zahlreiche Bilder aus den 50er, 60er und 70er Jahren hätte. Ist aber noch sehr unsicher, ob das klappt...
- Ah, danke. Genau das wollte ich hören. :) Die anderen Infos bei Bildrechten und Urheberrechtsfragen ließen alle heraushören, dass man für jedes Bild eine extra Mail senden muss - aber wenn es zusammenfassend geht, dann ist alles gut (einzeln wäre uns beiden zuviel Arbeit gewesen). Und um nochmal auf die "dubiosen mündlichen Absprachen" zu kommen: Erstens wäre das nicht nur mündlich, sondern er wird mir das schriftlich bestätigen und zweitens würde er mir eh nur genau die Bilder zukommen lassen, die er wirklich zur Verfügung stellen will (es ist nicht so, dass ich freien Zugriff auf sein Archiv habe). --maststef 13:18, 6. Okt. 2009 (CEST)
- Mal angenommen, du würdest einen neuen Account eröffnen, und dann so tun, als wärst du er... Wer würde das mitbekommen, wen würde das stören? --77.23.104.33 13:55, 9. Okt. 2009 (CEST)
Galerie und Verweis
Hallo,
ist es möglich in der Galerie einen externen Verweis zu erstellen für eigenes Wiki? Im Sinne von:
-
Rotkehlchen
<gallery>
Datei:Rotkehlchen_gr.jpg|Rotkehlchen|verweis=Vogel
</gallery>
turischt 80.218.141.182 02:56, 5. Okt. 2009 (CEST)
- Völlig klar ist mir die Frage nicht *zugeb* -- smial 14:24, 6. Okt. 2009 (CEST)
- Ich misch mich mal ein. Ich glaub er meint sowas:
- <gallery> Datei:Rotkehlchen gr.jpg|[[Vögel|Rotkehlchen]] </gallery>
- Ja vielen Dank.
- Wie mache ich das, dass das Bild (Datei:Rotkehlchen) auf einen externen Link verweist?
Turischt 13:54, 7. Okt. 2009 (CEST)
So: Hilfe:Bilder#Von_der_Bildbeschreibungsseite_abweichendes_Linkziel --maststef 14:26, 7. Okt. 2009 (CEST)
- Geht leider nicht, darum frage ich. Oder wenns doch gehen würde, wie sieht der Quelltext aus? Turischt 16:14, 7. Okt. 2009 (CEST)
- So ginge es (ohne Galerie):
- --Leyo 16:20, 7. Okt. 2009 (CEST)
- Nun ist aber das Problem, ich bräuchte eine Zeile mit 4-5 Elemente (Bild+Text) mit einem Abstand zwischen den Elementen. Meine Tabellen haben nicht funktioniert. Turischt 16:28, 7. Okt. 2009 (CEST)
Das geht:
Bei normalen Bildenr geht das auch (mit verweis), dafür darf es aber kein thumb sein. Bilder nebeneinander gehen mit einer Tabelle (halt in jede Zelle eine imagemap machen). --maststef 16:36, 7. Okt. 2009 (CEST) Nachtrag: Mit "externen Verweis" meinst du schon eine Addresse außerhalb des Wikis, oder? --maststef 16:39, 7. Okt. 2009 (CEST)
- Kannst du mir vielleicht den Code der Tabelle nennen, in der ich so Zwischenräume zwischen den Bildern habe, aso eigentlich eine Kopie der Gallery mit eigener Tabellenkonstruktion? Ja genau, ich hätte gerne Links ausserhalb des Wikis. Danke Turischt 18:13, 7. Okt. 2009 (CEST)
- Du kannst das ganze auch Faken: Beispiel, einfach den HTML-Quelltext genommen und in Wikisyntax umgewandelt. Der Umherirrende 18:43, 7. Okt. 2009 (CEST)
- Kannst du mir vielleicht den Code der Tabelle nennen, in der ich so Zwischenräume zwischen den Bildern habe, aso eigentlich eine Kopie der Gallery mit eigener Tabellenkonstruktion? Ja genau, ich hätte gerne Links ausserhalb des Wikis. Danke Turischt 18:13, 7. Okt. 2009 (CEST)
Achtung, bitte Lizenzen beachten! Wenn die Bilder public domain sind - kein Problem. Wenn sie aber CC oder gnu sind dann muss ja der Autor und die Lizenz genannt werden. Normalerweise geschieht dies durch den Link auf die Bilderseite und den dort angezeigten Infos. Wenn der nicht mehr vorhanden ist müssen diese Infos anderweitig angezeigt werden. --Nati aus Sythen Diskussion 19:08, 7. Okt. 2009 (CEST)
- Vielen vielen Dank. Turischt 11:19, 12. Okt. 2009 (CEST)
Hochkomma oder Apostroph
Das Bild ist im en:WP und unter Commons erreichbar. Nachdem es bereits im Artikel Rhomboeder erreichbar war, ist jetzt die Erreichbarkeit nicht mehr gegeben. Hat sich in letzter Zeit etwas an der Verlinkung von Bildern geändert. Das Bild ist in einer Galerie enthalten. (???) --Paule Boonekamp - eine Silbersonne 11:50, 22. Feb. 2009 (CET)
Kategoriesortierung auf Commons
Hallo, was mir immer wieder auffällt ist, dass Bildersortierungen in den Commons-Kategorien immer separat nach der manuellen Kategoriesortierung und nach dem Bildnamen erfolgen.
- Beispiel:
- Ein Bild namens "Objekt in Ort.jpg" wird bei einer Kategorisierung "[[Category:Objekt in Land|Ort]]" alphabetisch nach Ort einsortiert.
Nun dachte ich mir, wenn ich die Dateinamen gleich so wähle, dass der Ort vorne an steht (Bsp.: "Ort Objekt.jpg" mit Kat "[[Category:Objekt in Land]]"), wäre diese Kategoriesortierung evtl. nicht mehr nötig, was viele nachträgliche Kleinedits sparen würde. Dem ist aber nicht so. In der Kategorieansicht erscheinen erst Bilder mit manueller Kategoriesortierung, dann welche ohne und hinten an wieder welche mit dieser. Alle drei Blöcke sind in sich alphabetisch sortiert, jedoch nicht insgesamt.
Besteht eine Möglichkeit, mit entsprechender Softwareprogrammierung Bilder einheitlich entweder nach Katsortierung und, wenn nicht vorhanden, nach Dateinamen sortieren zu lassen? Wo wäre ggf. die richtige Anlaufstelle für so eine Anfrage? --Niteshift 08:13, 27. Apr. 2009 (CEST)
Extra-Thumbnails
Es gibt doch eine Möglichkeit, eine eigene Datei für Thumbnails einzubinden, um z. B. bei diesem Beispiel eine vernünftige Thumbnail-Darstellung zu ermöglichen, indem eine kleine Datei ohne Aliasingeffekte für den Thumbnail benutzt wird.
Ich meine mich zu erinnern, dass in der Hilfe eine Beschreibung mit einem Logo einer ostasiatischen Airline (oder so) war, bei dem sehr krasse Aliaseffekte in der Thumbnail-Darstellung auftauchten, finde es aber nicht mehr.
Oder kann man irgendwo angeben, dass beim Skalieren eines Bildes dieses tiefpassgefiltert wird? Verbraucht zwar mehr Ressourcen, sieht aber dafür besser aus.
-- Pemu 18:02, 14. Okt. 2009 (CEST)
- GIF wird einfach mies skaliert. -- smial 18:10, 14. Okt. 2009 (CEST)
- Warum? Und wie geht das nun mit dem alternative Thumbnail? Gut, das Problem konnte durch Konvertieren in PNG gelöst werden, aber trotzdem. -- Pemu 22:59, 25. Okt. 2009 (CET)
- Das Problem hatte ich gestern auch und selbst in der en nicht gefunden. Durch diesen Beitrag habe ich jetzt den Grund und das Logo in der Historie hier gefunden [22] und eine Version später gelöscht. Funktioniert seit etwa 2007 nicht mehr. Leider. Betrifft ja auch SVG. GIF ist doch ein Standardformat und verlustfrei. Bei 256 Farben bestimmt kleiner als PNG. --Kungfuman 19:02, 17. Nov. 2009 (CET)
- Hab ich noch nicht erlebt, dass eine PNG-Datei größer als eine entsprechende GIF-Datei war - auch wenn der Abstand durchaus schonmal nur wenige Bytes war. (pngrewrite und pngcrush existieren und haben natürlich ihren Sinn.) -- Pemu 12:36, 19. Nov. 2009 (CET)
- Müsste man noch konkret vergleichen. Gerade bei 1, 2 oder 16 Farben. Die GIF-Datei hier im Beispiel ist statt 4 jetzt 5 KB groß, dafür wirken die (vorhandenen) Striche doch schärfer (oder vielleicht sind sie dicker). Ganz abgesehen von der (damaligen) wesentlich höheren Verbreitung, Unterstützung und dem Aufwand der Konvertierung (zB wenn man viele Dateien hätte). Dann sollte man gar keine GIF-Dateien beim Upload zulassen oder die Nachteile groß darstellen. Bringt ja höchstens noch Sinn bei Animationen. War doch mit das erste Webformat. Da könnte man auch gleich JPG weglassen mit der Begründung es wäre verlustbehaftet und es gäbe andere, neuere Formate. Ärgerlich genug, dass man keine (kleinen) BMP Dateien hochladen kann. Von den SVG-Problemen ganz zu schweigen. --Kungfuman 15:14, 20. Nov. 2009 (CET)
- GIF bringt außer der Animationsmöglichkeit tatsächlich nichts, was PNG nicht auch könnte. GIF ist damit beinahe überflüssig geworden. Je nach Dateiinhalt kann PNG meist wesentlich platzsparender sein und ist nur selten größer. Wozu man BMP als unfreies und gleichzeitig beinahe unfähiges Format benötigen sollte, ist mir völlig unklar, BMP können ohne jede Einbußen jederzeit mit zahllosen kostenlosen Tools in freie, kompaktere Formate überführt werden. Ein Format wie GIF, das nur maximal 256 Farben unterstützt, hat freilich schon prinzipiell ein Problem beim Skalieren, weil eben u.U. nicht genügend Farben vorhanden sind, um die beim Skalieren erforderlichen Abstufungen zu erzeugen. -- smial 17:28, 20. Nov. 2009 (CET)
- Müsste man noch konkret vergleichen. Gerade bei 1, 2 oder 16 Farben. Die GIF-Datei hier im Beispiel ist statt 4 jetzt 5 KB groß, dafür wirken die (vorhandenen) Striche doch schärfer (oder vielleicht sind sie dicker). Ganz abgesehen von der (damaligen) wesentlich höheren Verbreitung, Unterstützung und dem Aufwand der Konvertierung (zB wenn man viele Dateien hätte). Dann sollte man gar keine GIF-Dateien beim Upload zulassen oder die Nachteile groß darstellen. Bringt ja höchstens noch Sinn bei Animationen. War doch mit das erste Webformat. Da könnte man auch gleich JPG weglassen mit der Begründung es wäre verlustbehaftet und es gäbe andere, neuere Formate. Ärgerlich genug, dass man keine (kleinen) BMP Dateien hochladen kann. Von den SVG-Problemen ganz zu schweigen. --Kungfuman 15:14, 20. Nov. 2009 (CET)
- Hab ich noch nicht erlebt, dass eine PNG-Datei größer als eine entsprechende GIF-Datei war - auch wenn der Abstand durchaus schonmal nur wenige Bytes war. (pngrewrite und pngcrush existieren und haben natürlich ihren Sinn.) -- Pemu 12:36, 19. Nov. 2009 (CET)
- Es wäre benutzerfreundlicher und einfacher, wenn GIF wieder (wie angekündigt) vollständig unterstützt und auch BMP (und andere Formate) zugelassen würden. Darum. Außerdem ging es ja speziell bei GIF natürlich um Bilder mit wenigen oder einer Farbe. Warum statt dem extrem kompatiblen BMP zB TIFF unterstützt wird ist genauso unklar. Genausogut könnte man ausschließlich JPG oder ausschließlich PNG erlauben. Es geht offenbar um die Lizenzfreiheit. Das geht natürlich auf Kosten der Benutzerfreundlichkeit und Kompatibilität. Siehe SVG und OGG. Die Formate haben sich weder bislang durchgesetzt und haben große Nachteile. Altbewährtes hingegen gerät immer mehr in den Hintergrund. Man könnte hier noch mehr philosophieren, aber das bringt ja nichts. Das Problem hier ist ja geklärt. --Kungfuman 18:45, 20. Nov. 2009 (CET)
Probleme mit neueren Versionen
Mir ist aufgefallen, dass manchmal ältere Versionen des Bildes angezeigt werden, obwohl neuere existieren. Woher kommt das und wie kann man das ändern? --Jobu0101 16:29, 21. Nov. 2009 (CET)
- Gleiches Problem fiel mir kürzlich auch auf (Commonsbilder). Normalerweise sollte das mit Löschen des Caches gelöst sein. Offenbar dauert es manchmal auch einige Tage bis die neuen Bilder zumindst als Miniatur geändert werden. Beim Vergößeren werden bei mir die aktuellen Bilder angezeigt. Vielleicht sollte man besser unter neuem Namen hochladen und die alten löschen. --Kungfuman 17:23, 21. Nov. 2009 (CET)
- Also ich habe das bei einem Bild vom 30.09.2009. Das ist schon etwas älter... --Jobu0101 17:25, 21. Nov. 2009 (CET)
- Das sind in aller Regel Cacheprobleme. Die können lokal beim eigenen Rechner auftreten, aber auch in den Server-Caches. Lustigerweise funktioniert purgen manchmal erst im zweiten oder dritten Versuch, keine Ahnung, woran das liegt. -- smial 18:55, 21. Nov. 2009 (CET)
- Also, dass es der eigene Rechner ist, habe ich ausschließen können. --Jobu0101 19:26, 21. Nov. 2009 (CET)
- Kann man das nicht irgendwie manuell auslösen? --Jobu0101 12:49, 22. Nov. 2009 (CET)
- Hilfe:Cache -- smial 13:42, 22. Nov. 2009 (CET)
- Es geht mir nicht um den privaten Cache im Browser, sondern den der Wikipedia. --Jobu0101 13:56, 22. Nov. 2009 (CET)
- Okay, in dem Artikel ging es um beides. Doch hier mal ein Beispiel Datei:Staccatospiel.png. Die drittletzte Note sollte ein H und kein A sein. Der Fehler wurde in der zweiten Version korrigiert. Trotzdem wird er noch falsch angezeigt. Nur eben beim Bild in Originalauflösung nicht. --Jobu0101 14:00, 22. Nov. 2009 (CET)
- Hilfe:Cache -- smial 13:42, 22. Nov. 2009 (CET)
- Kann man das nicht irgendwie manuell auslösen? --Jobu0101 12:49, 22. Nov. 2009 (CET)
- Also, dass es der eigene Rechner ist, habe ich ausschließen können. --Jobu0101 19:26, 21. Nov. 2009 (CET)
- Das sind in aller Regel Cacheprobleme. Die können lokal beim eigenen Rechner auftreten, aber auch in den Server-Caches. Lustigerweise funktioniert purgen manchmal erst im zweiten oder dritten Versuch, keine Ahnung, woran das liegt. -- smial 18:55, 21. Nov. 2009 (CET)
- Also ich habe das bei einem Bild vom 30.09.2009. Das ist schon etwas älter... --Jobu0101 17:25, 21. Nov. 2009 (CET)
- Wikipedia-Internes kann man wohl schlecht ändern. Das wird auch zwischendurch öfters geändert. Am einfachsten wäre ein erneuter upload. --Kungfuman 17:41, 22. Nov. 2009 (CET)
- Wird hier im Artikel Staccato, auf der Bildbeschreibungsseite und in voller Auflösung immer gleich angezeigt. Also vll. doch ein lokales Browserproblem? -- smial 21:45, 22. Nov. 2009 (CET)
- Ne, jetzt stimmt es. War wohl nur die ersten Tage falsch. Jetzt bleibt noch dieses Bild hier. Dafür existiert seit dem 30.09.2009 eine neuere schönere Version. Wieso wird die nicht angezeigt? --Jobu0101 22:16, 22. Nov. 2009 (CET)
- Habe das Thema auch einmal hier angesprochen, doch da meldet sich keiner. --Jobu0101 22:22, 22. Nov. 2009 (CET)
- Ich bin jetzt genau nach Anweisung in Hilfe:Cache vorgegangen, et voilá: Bild ist aktuell. -- smial 23:19, 22. Nov. 2009 (CET)
- Dankeschön. Bei mir hat das irgendwie nicht geklappt. Folglich muss ich irgendetwas falsch gemacht haben... --Jobu0101 10:25, 23. Nov. 2009 (CET)
- Das Hinterlistige ist, daß man den Erfolg der Aktion nicht direkt erkennen kann, sondern erst, nachdem man alle vorgeschlagenen Schritte durchgeführt hat und danach den browsercache auch noch geleert hat. Und wie oben schon angemerkt: Aus unerfindlichen Gründen klappt es anscheinend manchmal nicht gleich beim ersten Versuch. Hakelige Sache. -- smial 10:39, 23. Nov. 2009 (CET)
- Nun gut. Freue mich, dass es nun endlich stimmt. Wenn mir wieder mal ein Bild Probleme bereitet, werde ich mich wieder hier melden ;) --Jobu0101 12:51, 23. Nov. 2009 (CET)
- Das Hinterlistige ist, daß man den Erfolg der Aktion nicht direkt erkennen kann, sondern erst, nachdem man alle vorgeschlagenen Schritte durchgeführt hat und danach den browsercache auch noch geleert hat. Und wie oben schon angemerkt: Aus unerfindlichen Gründen klappt es anscheinend manchmal nicht gleich beim ersten Versuch. Hakelige Sache. -- smial 10:39, 23. Nov. 2009 (CET)
- Dankeschön. Bei mir hat das irgendwie nicht geklappt. Folglich muss ich irgendetwas falsch gemacht haben... --Jobu0101 10:25, 23. Nov. 2009 (CET)
- Ich bin jetzt genau nach Anweisung in Hilfe:Cache vorgegangen, et voilá: Bild ist aktuell. -- smial 23:19, 22. Nov. 2009 (CET)
- Wird hier im Artikel Staccato, auf der Bildbeschreibungsseite und in voller Auflösung immer gleich angezeigt. Also vll. doch ein lokales Browserproblem? -- smial 21:45, 22. Nov. 2009 (CET)
Breite + Höhe
Wie kann man die Breite und die Höhe des Bildes erstellen wie man es will. Also das man z.B. dieses Bild , welches nicht quadratisch ist, mit 20 x 20 px erstellt? --edwinvandersardiskussion 16:32, 19. Dez. 2009 (CET)
- Wenn du ein Bild quadratisch haben willst, mußt du es quadratisch zuschneiden. Wenn du eine Reihe Bilder auf eine gleiche Maximalgröße in x- und y-Richtung bringen willst, geht das mit einer Angabe wie "100x100px". Siehe zahlreiche Listenartikel wie z.B. Liste der Baudenkmäler in Unna. Die Bilder werden dadurch in einen quadratischen Bereich proportional eingepaßt. -- smial 16:50, 19. Dez. 2009 (CET)
Bilder aus ausländischen Wikipedias
Mir fehlt eine Erläuterung, ob bzw. wie ich Bilder einbinden kann, die nicht in Commons eingestellt sind, aber in ausländischen Wikipedias (z.B. http://en.wikipedia.org/wiki/File:Kektura_route.gif). -- Bernd Bergmann 17:39, 19. Dez. 2009 (CET)
- Es geht (noch?) nicht direkt. Sofern die Datei mit Commonsrichtlinien vereinbar ist, sollte man die nach commons verschieben. Das geht mit dem commonshelper bei anderen Sprachversionen genau so wie bei Bildern aus der deutschsprachigen WP. Darf sie nicht nach commons, wäre auf DE aber erlaubt, dann kann man sie nach DE kopieren. Dabei ist darauf zu achten, daß alle Urheber- und Lizenzinformationen erhalten bleiben. Bei dem verlinkten GIF sehe ich aber tiefschwarz, das ist ganz offensichtlich eine modifizierte Kopie irgendeiner gedruckten Karte, die jünger als 100 Jahre ist, meiner Meinung nach also hierzulande eine klare Urheberrechtsverletzung. Eventuell an die Kartenwerkstatt wenden, ob dort jemand eine Lösung für das Problem hat. Also entweder eine Karte kennt, die wir hier verwenden können oder eine neue Karte zeichnet. -- smial 18:12, 19. Dez. 2009 (CET)
Bild:Xframe_en.png wiederherstellen oder übersetzten
Tcha, das Bild sollte eigentlich mal übersetzt werden, was auch auf dessen (deutscher) Diskussionsseite stand. Vielleicht kann ja mal jemand das Bild (und seine Diskussionsseite) wiederherstellen oder besser noch, dessen Texte gleich ins Deutsche übersetzten und das dann hier und nicht bei Commons abspeichern. Ich sehe nämlich keinen Sinn darin, Bilder mit deutsch-sprachigen Inhalten ins englische Commons zu schieben, wo die wenigsten Deutsch-Sprecher noch etwas ändern können (oder wollen). Siehe dazu auch unter Wikipedia Diskussion:Dateiüberprüfung/Archiv/2009#Bild:Xframe_en.png.
--Konrad – 09:29, 25. Okt. 2009 (CET)
- Zudem sind mit der Übertragung nach Wikimedia Commons alle bereits erstellten deutsch-sprachigen Inhalte verloren gegangen und nicht wie in der Zusammenfassung behauptet wurde (Zitat:) „Sämtliche Metainformationen wurden korrekt übertragen.“[23]
- --Konrad – 10:09, 3. Nov. 2009 (CET)
Habe die Daten nun selbst bei Commons (teilweise) ergänzt. Der Rest wird dann wohl (irgendwann) weiter übersetzt werden.
--Konrad – 14:10, 30. Mär. 2010 (CEST)