Zum Inhalt springen

Hilfe Diskussion:Bilder

Seiteninhalte werden in anderen Sprachen nicht unterstützt.
aus Wikipedia, der freien Enzyklopädie
Dies ist eine alte Version dieser Seite, zuletzt bearbeitet am 3. Oktober 2009 um 12:25 Uhr durch FBE2005 (Diskussion | Beiträge) (Bilder einbinden: kl.Erg.). Sie kann sich erheblich von der aktuellen Version unterscheiden.

Letzter Kommentar: vor 15 Jahren von Konrad F. in Abschnitt Bilder einbinden

Diese Seite dient der Diskussion über Inhalt und Gestaltung der Seite Hilfe:Bilder. Technische Fragen zu Bildern gehören auf WP:FzW. Fragen zu rechtlichen Problemen können auf WP:UF gestellt werden.

Archiv
Wie wird ein Archiv angelegt?

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...

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)Beantworten

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...

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)Beantworten

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)Beantworten

Eigener Hint-Parameter wäre manchmal nützlich!

Eine Feder mit Rahmen

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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

Warum soll
{{Großes Bild|Panorama Schwerin Wasserturm Neumuehle.jpg|2000|Panoramabild Schwerins}}
eine größere Barriere als
[[Bild:Panorama Schwerin Wasserturm Neumuehle.jpg|2000px|thumb|center|Panoramabild Schwerins]]
Panoramabild Schwerins
darstellen? --Fomafix 13:57, 29. Jun. 2009 (CEST)Beantworten
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)Beantworten
Panoramabild Schwerins
Das Spricht aber alles nicht gegen die Vorlage:Großes Bild.
{{Großes Bild|Panorama Schwerin Wasserturm Neumuehle.jpg|750|Panoramabild Schwerins}}
geht genauso. --Fomafix 14:40, 29. Jun. 2009 (CEST)Beantworten
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)Beantworten
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)Beantworten
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)Beantworten
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)Beantworten
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)Beantworten
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)Beantworten
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)Beantworten
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 als 750px. 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)Beantworten
Mit HTML lässt übrigens ein Bild in der Breite des Browserfensters erzeugen:
<img width="100%" src="/media/wikipedia/commons/thumb/6/65/Panorama_Schwerin_Wasserturm_Neumuehle.jpg/750px-Panorama_Schwerin_Wasserturm_Neumuehle.jpg" alt="Panoramabild Schwerins" />
. 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:
.panorama img { width: 100%; height:auto }
--Fomafix 12:44, 30. Jun. 2009 (CEST)Beantworten
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)Beantworten
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)Beantworten
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)Beantworten
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)Beantworten
Bitte keine persönlichen Regeln aufstellen. --Fomafix 17:04, 5. Jul. 2009 (CEST)Beantworten
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)Beantworten
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)Beantworten
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)Beantworten
@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?Beantworten
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)Beantworten
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)Beantworten
Die Jetzt als Alternative Vorgeschlagene Option produziert z.B. sowas
360-Grad-Blick vom CN Tower

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)Beantworten

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)Beantworten
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)Beantworten
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)Beantworten
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)Beantworten

Mal so als Frage: Wo ist denn das hier genannte System ohne Maus im Einsatz? --Cobelius 19:58, 24. Aug. 2009 (CEST)Beantworten

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)Beantworten
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)Beantworten
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)Beantworten
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)Beantworten
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)Beantworten
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)Beantworten
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)Beantworten
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)Beantworten
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)Beantworten
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)Beantworten
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)Beantworten

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)Beantworten

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)Beantworten
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)Beantworten
Dann installiere dir endlich JAWS und versuche es selbst mal. -Marcela 15:48, 14. Sep. 2009 (CEST)Beantworten
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)Beantworten
(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)Beantworten
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)Beantworten
Stell am besten gleich noch ein Meinungsbild, ob der Mittwoch wirklich vor dem Donnerstag kommt. – Wladyslaw [Disk.] 15:55, 14. Sep. 2009 (CEST)Beantworten
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)Beantworten

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)Beantworten

Es geht um unnötige Scrollbalken. Ja bitte, wir hatten lange kein MB mehr. --Marcela 16:19, 14. Sep. 2009 (CEST)Beantworten
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)Beantworten
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)Beantworten
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)Beantworten
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)Beantworten
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)Beantworten
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)Beantworten
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)Beantworten
Bei mir nicht. Ich warte auf stichhaltige Argumente. – Wladyslaw [Disk.] 17:28, 14. Sep. 2009 (CEST)Beantworten
Hier mal ein paar, da es ja sowieso nicht viele geben könnte:
  1. 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
  2. Bei stark vergrößerter Seitendarstellung taucht keine weitere horizontale Scrollleiste auf, da die Vorlage mit der Seite skaliert
  3. 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)
  4. 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.
  5. Daraus folgt auch, dass die Vorlagenlösung konsistenter ist.
-- 17:42, 14. Sep. 2009 (CEST)Beantworten
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.
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.
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)Beantworten
"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)Beantworten
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)Beantworten
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)Beantworten
Tja, funktioniert nicht. Wunderbar. – Wladyslaw [Disk.] 09:28, 15. Sep. 2009 (CEST)Beantworten
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)Beantworten
Hier geht's weiter → Wikipedia:Meinungsbilder/Verwendung von Panoramabildern --DaSch/Feuerwehrkontrolle 16:33, 14. Sep. 2009 (CEST)Beantworten
Nö, hier und hier und hier und hier. Erst BITV lesen, dann diskutieren. --Marcela 16:42, 14. Sep. 2009 (CEST)Beantworten
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)Beantworten
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)Beantworten
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)Beantworten
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)Beantworten
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)Beantworten
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)Beantworten
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)Beantworten
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)Beantworten
<------------
Zu einem zufällig entdeckten, knuffigen Effekt habe ich hier mal eine Frage gestellt. -- smial 00:53, 25. Sep. 2009 (CEST)Beantworten

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. [1] [2] [3]

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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten
Oh mein Gott, ist das alles kompliziert. Ich schau mal. Danke. --92.117.60.45 11:12, 11. Aug. 2009 (CEST)Beantworten

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)Beantworten

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)Beantworten
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)Beantworten
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)Beantworten
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)Beantworten
Darf ich? Darf ich? -- smial 16:04, 15. Aug. 2009 (CEST)Beantworten
Wenn du magst. Kindergarden!--83.135.16.21 16:07, 15. Aug. 2009 (CEST)Beantworten
Kindergarten ist, mit Fußaufstampfen die eigene Position durchzusetzen. Oder es zu versuchen. -- smial 16:16, 15. Aug. 2009 (CEST)Beantworten
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)Beantworten

Ich finde miniatur ist WP:OMA-freundlicher? Matthias 10:46, 14. Sep. 2009 (CEST)Beantworten
Ich finde, bei thumb ist besser erkennbar, dass es sich nicht um Text der Bildunterschrift handelt. --Leyo 10:16, 18. Sep. 2009 (CEST)Beantworten

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)Beantworten
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)Beantworten
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)Beantworten

thumb|α350

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.Beantworten
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)Beantworten

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)Beantworten

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)Beantworten

Hochgeladene neue Dateienversion wird nicht immer angezeigt

Verwaltungsgliederung von Ainaro
Verwaltungsgliederung von Ainaro

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)Beantworten

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)Beantworten
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)Beantworten
Welche Breite in Pixel hat bei Dir das Bild? --Fomafix 00:23, 26. Sep. 2009 (CEST)Beantworten
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: Hatu Udo, Hatu Builico und Liste der Verwaltungseinheiten Osttimors --JPF ''just another user'' 13:30, 26. Sep. 2009 (CEST)Beantworten
Ich kann keine Probleme feststellen. Weder am linken noch am rechten Bild. Beide sind aktuell und zeigen /media/wikipedia/commons/3/3a/Sucos_Ainaro.png an. --Fomafix 10:31, 27. Sep. 2009 (CEST)Beantworten
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)Beantworten

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)Beantworten

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).[4]
--Konrad07:17, 27. Sep. 2009 (CEST)Beantworten

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)Beantworten

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)?
--Konrad12:29, 30. Sep. 2009 (CEST)Beantworten

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.Beantworten

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)Beantworten

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.
--Konrad12:22, 3. Okt. 2009 (CEST)Beantworten

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)Beantworten