Hilfe Diskussion:Bilder/Archiv/5

Abschnitt „Rahmenlose Einbindung (ohne Miniatur)“

Hallo Benutzer:Partynia, Benutzer:Diwas, mit diesem Edit vom 00:05, 13. Mär. 2018 habt ihr (ihr verzeiht bitte, das ich im folgenden nicht auseinander drösel wer was editiert hat und euch gemeinsam anspreche) versucht zu beschreiben, was man denn machen müsse um gerahmte und ungeramhmt Bilder nahe zusammen zu stellen. Das Projekt gleicht der Quadartur des Kreises. Grund:

Das umschließende Rechteck eines rahmenlosen Bildes entspricht immer den Proportionen des eingebundenen Bildes. Gerahmte Bilder haben immer links, oben und rechts einen festen Offset von 5px für den Rahmen. Unten haben sie einen Offset, der von vier Faktoren abhängt:

Länge/Worte der Bildunterschrift
Schriftart/Größe/Zeilenabstand der Bildunterschrift
feste Breiteangabe in px des Autors
Breitenangabe über 'hochkant=x'
Breitenangabe des Lesers
gerahmtes und ungerahmtes Bild können im Original unterschiedliche Proportionen haben

Das umschliessende Rechteck bei gerahmten Bildern ist also nicht proportional zum Ursprungsbild (und damit auch nicht proportional zum ungerahmten Bild), die Abweichung von der Proportionnalität hängt von vielen Faktoren ab und ist (mit den uns zur Verfügung stehenden Mittel) nicht berechenbar.

Damit kommt das ganze Projekt der quadratur des Kreise gleich. Wenn man Rechtecke mit verschiednen Proportionen nahe zusammen fügt, gibt es unvermeidlich Lücken!

Wenn man also gerahmte und ungerahmte Bilder nahe beieinander stellen will, muss man sich entscheiden ob die Höhe oder die Breite gleich sein soll. Da es der einfachere Fall ist, beschäftige ich mich mit der Breite (und man sieht, das selbst die Breite große Probleme macht).

In der ersten Version der Änderung wird schlicht Empfohlen, das rahmenlose Bild mit einer fixen Breite von 230px einzubinden. Wenn es denn gewünscht ist, rahmenlose und gerahmte Bilder mit gleicher Breite einzustellen, ist das in der Tat das Mittel der Wahl. Es funktioniert! Zwei Ergänzungen wären sinnvoll: zum einen sollte man empfehlen das gerahmte Bild ebenfalls mit fixer Breite (hier 220px) einzubinden – zum anderen kann man hier das ganze didaktisch ein bischen aufarbeiten (das Verhältnis 220/230px mit der 5px Rahmenbreite erklären). Dann lernt der Benutzer etwas (auch als Ergänzung: bei fixer Breite ohne Parameter 'mini' kann man sich den Parameter 'rahmenlos' sparen).

Dann wurde die Version mit fixer Angabe aufgehoben und durch den Parameter 'hochkant=1.39' ersetzt. Nachdem offenbar bemerkt wurde, das der Parmeter völlig falsch ist, wurde er inzwischen auf 'hochkant=1' gesetzt. Beide Versionen sind falsch.

Hier die Berechung für den Parameter 'hochkant' bei einem rahmenlosen Bild in Standardbreite 220px. Wir wissen, dass das rahmenlose Bild 230px breit sein muss. Daraus ergibt sich der Faktor 230:220 -> 1.04545:1. Und siehe da: der Paraameter 'hochkant=1.04545' funktioniert sehr gut. Dummerweise aber nur, wenn das geramte Bild die Standardbreite von 220px hat. Und wenn der Parameter 'hochkant' nicht für alle Breiten gleich ist, dann kann ich mir das ganze Hochkant-kuddelmuddel auch gleich sparen (wie gesagt: die fixen Angaben haben wenigsten didaktischen Wert).

Hintergrund, warum der Parameter 'hochkant' in die Beschreibung eingearbeitet wurde ist offenbar, das man die angemeldeten Benutzer berücksichtigen wollte, die in ihrem Style den Standardwert von 220px geändert haben. Und genau bei denen funktioniert es wie dargelegt nicht.

Wenn man man ganz zurück auf Start geht, dann würde ich sagen, das es wohl ein echter Sonderfall ist, wenn jemand rahmenlose und gerahmte Bilder eng zusammen einbinden will. Und wenn man von den Fällen, in denen ein Benutzer das möchte die Fälle herausfischt, in den das auch sinnvoll ist, das wird man auf eine sehr kleine Zahl kommen (ich schätze, das es Null ist ). Ich schlage daher vor, den kompletten Text auf Version vom 16:01, 31. Jan. 2018 zurück zu setzten.

Alternativ kann man andere Dinge in dem Abschnitt erwähnen. Beispielsweise das rahmenlose Bilder etwas problematisch sind weil die Lizenzbedinungen schwerer zu finden sind. Oder wie oben beschrieben, das der Paramter rahmenlos überflüssig ist wenn ich eine fixe Angabe mache und mini weg lassen. Auch auf die recht simple Berechnunung des Parameters 'hochkant' kann man an anderer Stelle näher eingehen. Es gibt viele sinnvolle Ergänzungen. Diese Ergänzung war es nicht. -- Summer • Streicheln • ~~Note~~ 16:36, 13. Mär. 2018 (CET)

PS: die Formulierung „Sollen rahmenlose Bilder möglichst den gleichen Raum einnehmen wie …“ ist hier falsch weil der Begriff Raum die dritte Dimension meint. --Summer • Streicheln • ~~Note~~ 16:50, 13. Mär. 2018 (CET)

@ Summer Danke für die ausführlichen Infos. Ich bin auf das Problem auf der Seite Frédéric Chopin#Anschlag und Klavierbau bei den beiden Bildern gestoßen. Ich wollte eigentlich nichts anderes, als dass sie gleich groß wie die übrigen mit mini eingebunden Bildern sind. Die Darstellung hat sowohl mit hochkant=1 als auch mit 230px funktioniert. Oder hast Du dafür eine bessere Lösung? Grüße --Partynia ^{∞ RM} 18:02, 13. Mär. 2018 (CET)

P.S. Übrigens moniert die Syntaxkorrektur das Nebeneinander von "rahmenlos" und "rand".--Partynia ^{∞ RM} 18:14, 13. Mär. 2018 (CET)

Drei Dinge:

mit deinem Edit wurden aus dem Link in meiner Signatur drei einzelne Punkte durch ein Zeichen ersetzt, das optisch drei Punkte zeigt. Dadurch ist meine Signatur vom Blaulink zum Rotlink geworden. Das wirst du vermutl. nicht mit Absicht gemacht haben und ich kann auch (hier und heute) mit dem Ergebnis leben. Du solltest das aber an geeigneter Stelle als Fehler melden. Es kann nicht sein, das Programme beim Editieren in Fremden Edits rumpfuschen und dabei noch echte Fehler hinterlassen (das die Syntaxkorrektur rahmenlos/rand moniert könnte ein Fehler vom gleichen Programm sein).
Ich würde gerne wie oben schon geschrieben auf die Version vor deinem ersten Edit zurücksetzen. Aktuell wird beispielsweise empfohlen den Parameter "hochkant=1" zu setzen. Der Paramter bewirkt aber rein gar nichts (stört also in Artikel nicht weiter - in einem Beispiel aber schon, weil der Benutzer ja nicht lernen soll unsinnige Dinge in Artikel einzufügen). Danach kann man dann sehen welche Änderungswünsche es gibt und sie ggf. umsetzen.
Wegen deinem Frédéric Chopin#Anschlag und Klavierbau Problem (möglicherweise hast du da ja garkein Probem mehr) schreibe ich dir auf deiner Disk umd nicht verschiedene Dinge zu vermengen. --Summer • Streicheln • ~~Note~~ 20:24, 13. Mär. 2018 (CET)

Vermutlich habe ich beim hochkant-Paramater eine Null zwischen 1. und 39 vergessen. 1.039 passte optisch bei verschiedenen Dateien sowohl mit persönlicher Einstellung 120px als auch 400px. Hingegen schien 1.04 bei einigen Kombinationen etwas zu breit. Gleiche Breite wäre natürlich die richtige Formulierung, nicht Raum. Vielleicht sollte man überlegen, eine Seite Hilfe:Bilder/Tricks und Kniffe anzulegen und hier zu verlinken. Bin mir nicht sicher, ob man solche Spezialitäten auf der Hilfseite, auf einer Extraseite oder gar nicht behandeln soll. Alle Spezialfälle, die man auf der Hilfeseite erwähnt, erschweren den Einstieg und das Auffinden der wesentlichen Informationen. Eine sehr große Seite schreckt auch ab. Grüße --Diwas (Diskussion) 23:51, 23:54, 13. Mär. 2018 (CET)

Bloß keine „Tricks und Kniffe“, entweder seriöse Doku oder nix.

Laut seriöser Dokus soll übrigens auch nur die erste Nach-Komma(Punkt)-Stelle gelten; also hochkant=1.039 gleich hochkant=1.0 gleich hochkant=1.

VG --PerfektesChaos 00:39, 14. Mär. 2018 (CET)

Benutzer:PerfektesChaos. Ich wusste nicht, das so grob gerundet wird und konnte es auch nicht recht glauben. Also habe ich es überprüft. Durch Rechnen und Reverse-Ingeneuring kann man sehen, das gerundet wird - aber an einer anderen Stelle als du vermutest!

Wie ich oben schrieb, müsste der berechnete Wert für 'hochkant' bei Standardeinstellung 1.04545 betragen (220px*1.04545=230px). Nun habe ich festgestellt, das die Software zwar in die Berechnung einige Nachkommastellen einfließen lässt, bei der Ausgabe aber auf 10px rundet. In der Ausgabe bei Hochkant bekommt man also nur auf 10 gerundete Werte wie 220px, 230px, 240px etc. Ein Wert von 1.022 ergibt noch eine Ausgabe von 220px; inkrementiere ich um eine Tausenderstelle auf 1.023, dann wird die Ausgabe auf 230px aufgerundet.

Es gilt also: alle Hochkantwerte zw. 1.023 und 1.068 erzeugen eine Ausgabe von 230px (bei Standardeinstellungen)

Oben schriebst du, das 1.039 auf 1 abgerundet würde. Das ist in sofern falsch, als die beiden Werte eine andere Ausgabe erzeugen weil technisch eben nicht vor dem Rechenprozess sondern erste am Ende gerundet wird. Und der Unterschied macht ganze 10 Pixel aus.

Damit ist auch der derzeitig unter '#Rahmenlose Einbindung (ohne Miniatur)' stehende Satz „Sollen rahmenlose Bilder möglichst den gleichen Raum einnehmen wie der Rahmen bei Verwendung des Parameters mini, kann die Bildgröße mit dem Parameter hochkant=1 angepasst werden:“ schlicht falsch (das darunter stehende Bsp. nat. auch).

Ich werde daher gleich den Hilfetext auf die Version vom 13 März zurücksetzen. Sas ist letzte Version, bevor das Thema 'Gleichheit von gerahmten/ungerahmten Bildern' angegangen wurde.

Ich bin leidenschaftslos, ob man das Thema wirder neu einfügt. Wenn es gewünscht wird, versuche ich mich gerne selbt daran. Ich würde aber dringend vorschlagen, es mit frestn Pixelangaben zu machen. Auch Benutzer mit wenig Erfahrung ist es verständlich, das die Standartausgaben 220px plus 5px rechts und links ist. Das leuchtet jeden ein während 'hochkant' schwer verständlich ist und ein Eigenleben hat. Ich will es nicht näher ausführen - aber für angemeldete Benutzer die an den Standartwerten rumgefummelt haben werden wir es mit keiner der beiden Methoden korrekt hin bekommen. Aber diese Benutzer wissen ja ohnehin, das manches bei ihnen anders aussieht.

Zu den Tipps und Tricks: ich möchte keine Trickkiste anlegen, aus der sich Spielkinder bedienen um den Spieltrieb zu befriedigen. Die Hilfetexte sollten das anbieten, was im Alltag gebraucht wird. Für weitergehende Problem kann man echte Menschen (oder auch mal einen Hund) fragen. --Summer • Streicheln • ~~Note~~ 12:29, 14. Mär. 2018 (CET)

H:B #hochkant:

„Die mögliche Schrittweite ist ein Zehntel.“
„Die Breite der so berechneten Vorschaubilder wird immer auf den nächsthöheren 10er-Wert aufgerundet.“

RTFM --PerfektesChaos 12:39, 14. Mär. 2018 (CET)

„Read the fucking manual“: Lesen ist Silber - Verstehen Gold --Summer • Streicheln • ~~Note~~ 13:20, 14. Mär. 2018 (CET)

Demnach war meine ursprüngliche Einbindung mit "rahmenlos" + "Rand" + "230px" wohl die beste Lösung, um eine Größendarstellung (fast) wie bei "mini" zu erreichen? --Partynia ^{∞ RM} 13:33, 14. Mär. 2018 (CET)

Ganz oben schrieb ich bereits: „In der ersten Version der Änderung wird schlicht Empfohlen, das rahmenlose Bild mit einer fixen Breite von 230px einzubinden. Wenn es denn gewünscht ist, rahmenlose und gerahmte Bilder mit gleicher Breite einzustellen, ist das in der Tat das Mittel der Wahl“. Ich gebe dir also zum zweiten Mal recht :-). Auf Rahmenlos-Zeug zu setzten ist m.E. nicht gut. --Summer • Streicheln • ~~Note~~ 13:38, 14. Mär. 2018 (CET)

Danke. Aber dann könnte man doch dies als Hinweis hineinschreiben (auch wenn es nicht häufig "rahmenlos" vorkommen dürfte.--Partynia ^{∞ RM} 13:41, 14. Mär. 2018 (CET)

Mein „... Wenn es denn gewünscht ist ...“ (Ausschnitt aus Zitat) besagt ja, das ich keine prinzipiellen Einwände habe (allerding bin ich auch nicht leidenschaftlich dafür!). Man sollte sich nur bemühen, es versändlich einzubinden.

Unabhängig von allem denke ich, das es erstmal gut wäre, den umseitigen Satz „Angemeldete Benutzer können die Bildgröße der Vorschaubilder in ihren Benutzereinstellungen [...] festlegen; für nichtangemeldete Leser erscheinen diese Bilder mit einer Bildbreite von 220 Pixeln“ aus dem Abschnitt „Vorschaubilder (Miniatur)“ zu ergänzen. Dort sollten man dem Benutzer sagen, das ein Bild mit Rahmen 10px breiter ist. Das trägt so oder so oder so oder so dem Verständnis bei.

Zum Parameter Rahmenlos: das ist eigentlich ein Psyeudoparamter. Um auf die Bildbreite von 230px zu kommen, musst du den Parameter 230px einfügen. Fügst du den Parameter 230px aber ein, dann kannst du wiederum Rahmenlos gleich weg lassen. Schau dir nebenstehendes Beispiel im Quelltext an: der Parameter "Rahmenlos" und "220px" bewirken das gleiche ... benutzt du den einen, kannst du den anderen weg lassen.

Aus der Tatsache, das der Parameter Rahmenlos nur ein Pseudoparamter ist, kannst du auch ableiten, das man deinen "Trick" auch unter dem Abschnitt „#Feste Skalierung“ oder „#Vorschaubilder (Miniatur)“. Du hast also aus didaktischen Gründen drei Ort zur Wahl. Und ich persönlich würde unter „#Vorschaubilder (Miniatur)“ schreiben, das ein geramtes Bild brutto 230px breit ist und exakt an der Stelle schreiben, wie man ein Bild ohne Rahmen auf exakt 230px Breite bringen kann. -- Summer • Streicheln • ~~Note~~ 15:28, 14. Mär. 2018 (CET)

Vergleiche mal:

Also ist die Angabe 230px besser. Es bleibt das Problem, dass die Syntaxkorrektur das Nebeneinander von "rahmenlos" und "rand" moniert.--Partynia ^{∞ RM} 17:06, 14. Mär. 2018 (CET)

Die Behauptung unter „#Vorschaubilder (Miniatur)“ schreiben, das ein geramtes Bild brutto 230px breit ist ist schlicht und einfach falsch.

Die Aussage würde lauten: Das Bild ist so breit wie die individuelle Benutzereinstellung für „Miniatur“ es vorsieht, hinzu kommen einige Pixel für den Rahmen. Die Frage, wie viele Pixel, hängen davon ab, ob Mobilgerät oder Desktop und in letzterem Fall welche Skin, und ganz generell sind das keine dokumentationsfähigen Konstanten, sondern Werte, die die MediaWiki-Software ohne Vorwarnung oder auch nur Hinweis jederzeit um ein oder zwei Pixel mehr oder weniger ändern könnte.

Der Teil der Aussage Das Bild ist so breit wie die individuelle Benutzereinstellung für „Miniatur“ es vorsieht ist eine triviale Null-Aussage, weil das nun mal die Definition der Benutzereinstellung ist.

Das Ganze hier hat absolut null zielführenden Wert, und die Parameterkombination ist ansonsten unzulässig.

VG --PerfektesChaos 18:06, 14. Mär. 2018 (CET)

Es geht ja nur um den äußeren Eindruck und nicht um Programmierfeinheiten. Übrigens: die Parameterkombination steht so ausdrücklich bei der Vatikan-Fahne. LG --Partynia ^{∞ RM} 18:21, 14. Mär. 2018 (CET)

@Partynia: das du das Vatikanflaggenbeispiel kennst, zeigt, dass du das Manual gelesen hast. Im Sinne von RTFM (siehe oben) wird das PC sicher freuen. --Summer • Streicheln • ~~Note~~ 23:35, 14. Mär. 2018 (CET)

@PC: die Aussage, das Bilder mit Rahmen 230px breit sind ist in letzter Konsequenz nicht allgemeingültig (du kannst gerne markigere Worte dafür benutzen). Dabei muss ich anmerken, das mich ein Gruppe/Ausnahme kalt läßt: wer mit Skins spielt, auf den brauchen Autoren keine Rücksicht nehmen (Ausnahmen sind Menschen, die Schwierigkeiten mit dem Umgang mit Rechnern haben - Rotgrünverwechsler etc. .... also Gruppen, die wir allzugern hinten runter fallen lassen). Wirklich ernst nehmen tut ich nur das Argument mit den Mobilgeräten. Das Arugment ist gewichtig - kann wegen mir auch Ausschlaggebend sein. Für die, die es möglicherweise nicht wissen: ganz unten rechts kann man auf "Mobile Ansicht" umschalten. --Summer • Streicheln • ~~Note~~ 23:35, 14. Mär. 2018 (CET)

Annotierte Mona Lisa

Eben habe ich dieses Beispiel eines annotierten Bilds aus der Hilfe-Seite herausgenommen

 
  {{Annotiertes Bild
  | image = Leonardo da Vinci 043-mod.jpg
  | image-width = 2000
  | image-left = -825
  | image-top = -1100
  | width = 250
  | height = 250
  | float = left
  | annotations =
  | caption = Bildausschnitt
  }}

Der Grund ist, dass das Bild bei mir als komplettes Vollbild angezeigt wurde. Das einen Großteil des Fensters engenommen und einiges vom normalen Text überdeckt. Der Beschreibung entnehme ich, dass eigentlich nur ein kleiner Ausschnitt dargestellt werden sollte. An der Stelle hat also die Vorlage nicht funktioniert.
Mein WWW-Browser ist Firefox 52.9.0 (64-bit), Wikipedia-Skin ist ~~"modern"~~ "timeless". -<)kmk(>- (Diskussion) 23:26, 3. Sep. 2018 (CEST)Korrektur: Mein Skin ist nicht "modern", sondern "timeless". Hoffe, das hat nicht zu zusätzlicher Verwirrung bei der Fehlersuche geführt. -<)kmk(>- (Diskussion) 03:34, 5. Sep. 2018 (CEST)

CC: Ghilt als Ersteller der Vorlage.

Das liegt dann wohl am Skin, denn der selbe negative Effekt tritt leider auch in der mobilen Ansicht (→Vorlage:Annotiertes Bild) auf. Das wäre eventuell ein Fall für die Techniker (WP:Technik/Werkstatt?), in anderen Skins beispielsweise Vector, funktioniert das, da ist dann nur der Bereich um den Mund (von Nasenspitze bis Kinn) sichtbar. Da so etwas aber wohl auch in Artikeln verwendet wird (Beispiel) sollte da „dringend“ eine Anpassung erfolgen. Glücklicherweise gibt es nur „sehr wenige Einbindungen im ANR“ so etwas verschreckt doch sehr. Ich bin da auch neulich drüber gefallen, dass es mobil die Seiten total verunstaltet, dass es auch bei anderen Skins so ist, wusste ich da noch nicht. --Liebe Grüße, Lómelinde Diskussion 07:34, 4. Sep. 2018 (CEST)

Ja, die Technik-Werkstatt scheint da angebracht, Grüße, --Ghilt (Diskussion) 10:18, 4. Sep. 2018 (CEST)

Na ja, es ist deine Vorlage, würdest du dich dann bitte darum kümmern? --Liebe Grüße, Lómelinde Diskussion 10:24, 4. Sep. 2018 (CEST)

Antwort auf den →kurzen Zwischenruf

Das ist kein Arbeitsauftrag es war lediglich die Bitte dass du dich als Ersteller der Vorlage darum kümmerst, genau wie ich mich um alle Seiten kümmere, die ich erstellt habe, eigentlich eine Selbstverständlichkeit, es ist unfreundlich sich hinzustellen und zu sagen, ich habe sie nur übernommen. Und zudem auch völlig unverständlich, wenn etwas derartige Fehler verursacht. --Liebe Grüße, Lómelinde Diskussion 11:01, 4. Sep. 2018 (CEST)

Das sehe ich anders, aber die Vorlage hatte ich schon in der Technikwerkstatt eingestellt. --Ghilt (Diskussion) 11:12, 4. Sep. 2018 (CEST)

Hallo @KaiMartin: funktioniert die Darstellung jetzt? Grüße, --Ghilt (Diskussion) 13:34, 4. Sep. 2018 (CEST)

Hallo Ghilt. Ja! Jetzt funktioniert es. Ich bekomme nur die Mundpartie zu sehen. Danke für die schnelle Reaktion! ---<)kmk(>- (Diskussion) 03:37, 5. Sep. 2018 (CEST)

Prima, die Vorlage habe ich gestern aus der en-Version einfach darüber kopiert, viele Grüße, --Ghilt (Diskussion) 09:13, 5. Sep. 2018 (CEST)

@Ghilt: wenn ich die Idee eines Kollegen aufgreife und Erfolg habe, lasse ich ihn am Erfolg teilhaben. Möglicherweise bin ich aber ein bisschen altmodisch. --Summer • Streicheln • ~~Note~~ 10:18, 5. Sep. 2018 (CEST)

Bitteschön, also: Summer meinte dort, dass die en-Version in der Mobilansicht funktioniert, Dankeschön, --Ghilt (Diskussion) 10:21, 5. Sep. 2018 (CEST)

... und Summer meinte: „Work Arround: ohne viel zu Analysieren würde ich die de-Vorlage einfach mit der en-Vorlage überschreiben ...“. Danke also, das du meine Idee ausgeführt hast :-). --Summer • Streicheln • ~~Note~~ 10:31, 5. Sep. 2018 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Ghilt (Diskussion) 09:13, 5. Sep. 2018 (CEST)

Falsche Formulierung auf Hilfeseite

_hochkant=1.02272728 (ergibt einen Sprung auf 230px)

Der zweite Satz von „Zu beachten ist, dass der Faktor bei Dezimalbrüchen mit Punkt anstatt Komma angegeben werden muss (Beispiel: 1.8 anstatt 1,8). Die mögliche Schrittweite ist ein Zehntel“ ist falsch. Die Grenze für das Umschalten von 220px auf 230px liegt bei ((230px+220px)/2)/220px -> 225px/220px was einen Wert von 1.0227272727272727 ergibt. Im Quelltext zu dem nebenstehenden Beispiel sieht man, das der Bereich an dem Umgeschaltet wird von der Software exakt berechnet wird (PHP rechnet da intern wohl mit Real). Erst nach der Berechung mit exakten Werten rundet die Software auf 10px. --Summer • Streicheln • ~~Note~~ 13:07, 14. Mär. 2018 (CET)

Wohl nicht; intern wird mit voller Genauigkeit gerechnet, aber auf das Endergebnis bezogen.

Ist mini im Spiel, gelten die 10px hinterher, ansonsten nur die (abgeschnittenen) Zehntel.

Mir scheint die Hilfeseite richtig; aber die Zusammenhänge sind komplex und das gesamte Unterfangen hier wenig zielführend.

VG --PerfektesChaos 14:57, 14. Mär. 2018 (CET)

Der Satz „Die mögliche Schrittweite [des Paramter Hochkant] ist ein Zehntel“ ist definitv falsch. Nebenstehend siehst du, das ein Hunderstmillionstel ausreichen kann. --Summer • Streicheln • ~~Note~~ 15:35, 14. Mär. 2018 (CET)

PS: die Zusammenhänge sind hier nicht Komplex ... das ist im Gegenteil popelig einfach. Die Software akzeptiert viele Stellen hinter dem Komma, rechnet damit exakt und ganz am Ende vor der Ausgabe des Ergebnis rundet sie auf volle Zehner. Ich würde das sogar gute Programmierung nennen. -- Summer • Streicheln • ~~Note~~ 15:40, 14. Mär. 2018 (CET)

Das gilt alles nur für mini, bei nicht-mini greifen die Zehntel.

Die mini wiederum hängen von der Benutzereinstellung ab; diese kann zurzeit 120, 150, 180, 200, 220, 250, 300, 400px betragen, was sich im Lauf der Jahre aber ändern könnte.

Damit der Bild-Cache im Server nicht lauter Vorschaubilder halten muss, wird auf ganze Zehner abgeschnitten (nicht gerundet, wenn ich den Algorithmus recht erinnere; unter dem Maximalwert den nächstkleineren).

Deine Rechnerei gilt erstmal nur für dich persönlich, weil du offenkundig 220px eingestellt hast. Leser mit anderer Einstellung sehen aber eine andere Breite und bekommen ggf. andere Ergebnisse.

Die ganzen Zehntel gelten für nicht-mini, dann wird die Höhe betrachtet, dann das Ergebnis auf ganze Pixel gesetzt.

Diese gesamte Rumrechnerei hier und im Abschnitt drüber läuft völlig am Zweck des hochkant vorbei und ist für die Katz. Dem Artikel bringt es nichts.

Die internen Berechnungsmodalitäten haben sich in den letzten anderthalb Jahrzehten immer mal wieder etwas geändert und können auch zukünftig betreffend Rundung usw. anders laufen. Es ist absolut sinnlos, hier mit Nachkommastellen den halben Pixeln nachzujagen.

VG --PerfektesChaos 16:09, 14. Mär. 2018 (CET)

(Nach links Ausgerückt)

Als Wiederholung damit keine Missverständnisse aufkommen: Der Satz „Die mögliche Schrittweite [des Parameter Hochkant] ist ein Zehntel“ ist definitiv falsch. Defintiv wird ein Wert mir vielen Stellen hinter dem Komma (Dezimalpunkt) eingelesen und zur Berechnung herangezogen. Und kompliziert wird es nur, weil du es kompliziert machst.

Du verkomplizierst das ganze, indem du persönliche Benutzereinstellungen betrachtest. Lass das weg. Macht die einfache Sache nur kompliziert.
Du schreibst von Server-Cache etc. Alles nur komplexes Zeug. Die am heimischen Bildschirm angezeigte Bildgröße wird nicht vom physischen Bildparametern sondern von den Paramtern width/height des img-Tags bestimmt. Pures HTML das von der Wikisoftware generiert wird. Simpel
Das Bild der Messingfigur (heute auch auf der Hauptseite) habe ich in diesem Thread zweimal mit dem Parameter mini eingebunden um dir zu zeigen, das der Parameter Hochkant mindestens bis zur 8ten Stelle hinterm Komma ausgewertet wird. Im Thread darüber habe ich das Bild fünfmal eingebunden - vier davon OHNE den Parameter mini. Damit wäre wohl klar, das deine Vermutung bezüglich des Parameters mini falsch sind.

Wirf alle komplizierten Gedanken über Bord und beschränk dich auf das Einfache. Dann ist klar, dass das Handbuch falsch ist. --Summer • Streicheln • ~~Note~~ 16:52, 14. Mär. 2018 (CET)

@PC: Also ich habe als IP logischerweise nicht irgendwas eingestellt, und ich sehe die nebenstehenden Bilder in unterschiedlicher Grüße. 129.13.72.197 17:39, 14. Mär. 2018 (CET)

@Benutzer:PerfektesChaos: da Worte dich nicht überzeugen, versuch ich es mal mit einer hoffentlich selbstredenden Tabelle (Effekt bei Standardeinstellung sichtbar):

Hochkantwert	Bild
2.0
2.02273
2.06819
2.1
2.11364
2.15910
2.2
2.20455
2.25001
2.29546
2.3
2.34091
2.38637
2.4

Die Hochkantwerte mit 5 Nachkommastellen wurden wie oben beschrieben berechent und liegen genau an der Schwelle, an der das Bild vergrößert wird. Substrahiert man von dem jeweiligen Wert 0.00001, dann wird das Bild sprunghaft kleiner. --Summer • Streicheln • ~~Note~~ 12:22, 15. Mär. 2018 (CET)

Ich sehe hier nirgends einen Unterschied, die Bilder sind alle jeweils exakt gleich breit, sowohl die beiden oben anfangs, als auch die in der Tabelle (natürlich nur innerhalb der jeweiligen Gruppe). Solche merkbefreiten Spielereien dienen nichts sinnvollem, das hängt primär von den persönlichen Einstellungen, von den Browsereinstellungen, dem Ausgabegerät und sonstwas ab, wer meint damit irgendwas für alle gleich machen zu können, oder auch nur ein "schönes Seitenlayout" generell hinzubekommen, der hat den Schuss nicht gehört. Grüße vom Sänger ♫ ^(Reden) 14:08, 9. Mai 2018 (CEST)

Skalierung der Bildgrößen auf eine Nachkommastelle zu wenig

Wiederholt wurden im Artikel Schweinfurt bei der Skalierung der Bildgrößen zweistellige Nachkommastellen (linkes Bild) durch eine halbautomatische Ersetzung auf eine Stelle reduziert (rechtes Bild). Dadurch wurde im langen Artikel das Layout vieler Bilder zerstört und ich musste per Hand alles wieder reparieren.

An diesem Beispiel erkennt man zweifellos zwei Dinge:

1.: Für eine gute Bildgestaltung benötigt man 2 Nachkommastellen

2.: Die halbautomatische Ersetzung sollte entsprechend geändert werden

Grüße --Kim117 (Diskussion) 21:29, 7. Mai 2018 (CEST)

Bitte hilf mir auf dei Sprünge: Ich sehe keinen wesentlichen Unterschied zwischen den beiden Bildern. --Digamma (Diskussion) 22:14, 7. Mai 2018 (CEST)

Der Unterschied liegt allein bei der Bildlegende: links kompakt im Kasten mit 3 Zeilen, rechts zerrissen in 5 Zeilen, wobei die Überschrift in 2 Zeilen aufgespaltet wurde. Also eine doppelte Verschlechterung: 1. Grafik, mit unnötigen Platzverbrauch, was bei Bildern auf der linken Seite weitere Zerstörungen des Layouts nach sich ziehen kann, durch Versetzung der nachfolgenden Abschnitts-Überschrift nach rechts oder bei nachfolgenden blauen Listen-Punkten, die dann ins Bild hineingehen. 2.: Die Bildlegende wird unübersichtlicher und schwerer lesbar. Fazit: durch halbautomatische Reduzierung auf eine Nachkommastelle kann im schlimmsten Fall sogar ein ganzer, grafisch ausgefeilter Artikel formal ruiniert werden. --Kim117 (Diskussion) 08:00, 8. Mai 2018 (CEST)

Ich sehe unangemeldet und angemeldet zwei völlig verschiedene Unterschiede, angemeldet geht es um 2 vs. 3 Zeilen Bildunterschrift, unangemeldet waren es iirc 5 vs. 6 Zeilen. Von der Lesbarkeit des Karte selber her war unangemeldet eher nix zu erkennen, angemeldet geht es so. Das Problem mit der Darstellung von Bildern ist die Abhängigkeit von persönlichen Einstellungen und den Endgeräten, da von der Darstellung auf dem eigenen Bildschirm/Tablet/Wischhandy auf allgemeine Aussagen zu schließen, ist i.d.R. eher nicht möglich. Grüße vom Sänger ♫ ^(Reden) 08:29, 8. Mai 2018 (CEST)

Hallo Benutzer:Kim117, es ist schon ein witziger Zufall. Im Abschnitt #Falsche Formulierung auf Hilfeseite hier drüber habe ich mir den Mund fusselig geredet, das die Wikisoftware den Parameter hochkant mehr als nur eine Stelle hinter dem Komma auswertet (auch wenn mir da bis dato nicht zugestimmt wurde, hat jedenfalls niemand revertiert als ich die falsch Aussage auf der Hilfeseite löschte. Und nun sehe ich, das du genau diesen Parameter auf ein Hundertstel ausreizt.

Zu deinem Problem: über den Parameter hochkant kannst du, sofern der Benutzer Standardeinstellungen belassen hat, die exakte Darstellungsbreite eines Bildes vorgeben. Indirekt gibt du damit auch die Breite vor, die für die Bildunterschrift zur Verfügung steht. Da kannst aber leider über die Breite des Textfelds NICHT die Zeilenumbrüche exakt steuern. Der Grund: die Umbrüche werden im wesentlichen über den Zeichenfont gesteuert. Und der ist von Betriebssystem, Browser und Vorlieben des Benutzers abhängig.

Anders formuliert: wo du drei Zeilen siehst, erscheinen bei anderen Benutzern nur zwei oder auch vier Zeilen. Du kannst etwas mit erzwungenen Zeilenumbrüchen (<br />) und geschützten Leerzeichen ( ) arbeiten ... alles andere ist aussichtslos (es gibt noch etwas härtere Tricks ... aber die machen alle Probleme). --Summer • Streicheln • ~~Note~~ 14:37, 8. Mai 2018 (CEST)

@Lómelinde: an dich die Bitte, Kürzen von Hundertstelangaben wie hier zu unterlassen. Ich denke, es ist inzwischen nachgewiesen das die Hundertstelangaben bei Hochkant einen Effekt haben (können). Du solltest es einfach respektieren, wenn andere das Hundertstel verwenden wollen. --Summer • Streicheln • ~~Note~~ 14:54, 8. Mai 2018 (CEST)

Ich tue das nicht. --Liebe Grüße, Lómelinde Diskussion 15:14, 8. Mai 2018 (CEST)

Um mich als Programmierer des hochkant-Parameters mal einzumischen: Ihr könnt beliebig viele Nachkommastellen reinschreiben, die werden auch berücksichtigt. Aber: Das damit erstellt Thumbnail wird immer auf eine glatte Zehnerzahl gerundet: For caching health: If width scaled down due to upright parameter, round to full __0 pixel to avoid the creation of a lot of odd thumbs.. So meine damalige Begründung, die auch im PHP-Code von Linker.php zu finden ist. Mit anderen Worten: 300 Pixel * 0,75 (der Standard von hochkant) = 225 Pixel, gerundet zu 230 Pixel. Ohne Rundung besteht einfach die Gefahr, dass der Thumbnail-Cache mit unendlich vielen Werten "zugemüllt" wird. Im übrigen pflichte ich Summer bei: Bitte versucht nicht, pixelgenau Bild und Bildunterschrift in Einklang zu bringen. Dafür ist das Web nicht ausgelegt. Zu viele Faktoren spielen bei der Darstellung eine Rolle: Schriftart, Browser, Betriebssystem, benutzerspezifische Thumbnailgröße, mobile Darstellung usw. — Raymond ^Disk. 15:33, 8. Mai 2018 (CEST)

Auch das tue ich nicht. Die Umstellung erfolgt per Skript und nicht auf meinen speziellen Wunsch oder nach meinen Vorlieben oder einer zusätzlichen persönlichen Konfiguration.

Ich hatte aufgezeigt, wie man Bildlegenden anders gestalten kann, wenn es tatsächlich eine Legende zu der Abbildung und eben nicht die normalerweise zu erwartende Bildbeschreibung sein soll. Für mich gehört da nur ein sehr kurzer Text hin, der beschreibt was das für ein Bild ist Was das Bild darstellt = Übersichtskarte der Bomberoffensive im Juni 1944.

Ich kürze da aber tatsächlich manchmal bewusst und beabsichtigt den Text und verpacke einen Teil in ref-Tags, damit die Bildlegende nicht so unansehnlich überquillt. Was beim einen gut aussehen mag zeigt bei anderen Murks an. Und überfüllte Bildlegenden empfinge ich als sehr störend. --Liebe Grüße, Lómelinde Diskussion 15:52, 8. Mai 2018 (CEST)

Ich sah bisher angemeldet wie unangemeldet bei extrem unterschiedlichsten persönlichen Schriftgrößeneinstellungen in meinen beiden Notebooks mit sehr unterschiedlichen Bildschirmgrößen und bei unterschiedlichen PC's in diversen Stadtbüchereien bei einer Bildlegende mit zwei Nachkommastellen immer überall das exakt selbe Layout, mit selben Zeilenumbruch. Abweichungen gibt es offensichtlich demnach nur in selteneren Fällen, die dann nicht als Maßstab dienen sollten (und mobile Geräte sollten sowieso nur eine Nebenrolle spielen, da man es im Webdesign nun mal nicht allen Recht machen kann). Und auch im seltenen, obigen Fall waren es 2 vs. 3 bzw. 5 vs. 6 Zeilen. Also selbst hier bei zwei Nachkommastellen ein besseres Ergebnis als bei einer. Die Sache ist doch eindeutig: zwei können zu besseren Ergebnissen führen, als eine. --Kim117 (Diskussion) 12:09, 9. Mai 2018 (CEST)

Hi Kim117, ich bin ja voll bei dir, das man zwei Stellen bei dem Hochkantparameter verwenden darf (unter Strich ist es übrigends so, das man mit einer Nachkommanstelle 20px Sprünge hat während es bei 2 Nachkommastelle 10px Sprünge sind). Ich möchte dir nur trotz deines Test die 'Illusion' nehmen, dass du Zeilenumbrüche über Breitenangabe des Textfensters steuern kannst. Ein ganz simples Bsp.: ein Brillenträger wählt die Schrift auf seinen Mobile so, das er auch ohne Brille lesen kann. Schon stimmen die Umbrüche nicht mehr. Und ironischerweise gibt man dann genau dem Clientel, das mehr Mühe beim Lesen hat und gute Formatierung am dringensten bräuchte, die schlechteste.

Versteh mich bitte nicht falsch - ich will dich nicht von einer bestimmten Technik überzeugen. Aber HTML-Dokumente geben dem Brower beim Zeilenumbruch viel Spielraum. Sieh meinen Betrag mehr als Hilfestellung oder Anregung denn als Kritik (ich werde ganz sicher nicht in deinen Artikel nacheditieren). --Summer • Streicheln • ~~Note~~ 12:38, 9. Mai 2018 (CEST)

Fummeleien der Art 1.0 → 1.03 sind sinnfrei.

Die Breite eines Miniaturbildes hängt von den Benutzereinstellungen ab; nicht angemeldete Leser erhalten zurzeit 220px (ändert sich ab und zu) und angemeldete können 120px, 150px, …, 250px, 400px einstellen.
Die Breite von Texten hängt generell von den Font-Einstellungen bei den Lesern ab; welche Schriftart im Browser vorgegeben, und in welcher Größe, und wie gut sind die Augen des Lesers? Das bedingt die Breite der Buchstaben, und welches Text-Layout sich daraus ergibt, aus deren Aufsummierung.
Die Desktop-Skins bewirken teilweise bei identischen Browser-Vorgaben kleine Unterschiede in hier relevanten Details. Insbesondere aber auf Mobilgeräten werden völlig andere Darstellungkonzepte verfolgt, die sich obendrein häufig ändern.
Bilder werden in Pixeln px bemessen; Schriftzeichen in Maßeinheiten em und derlei. Das Verhältnis beider Maßeinheiten ist signifikant von Geräten und Betriebssystemen und Browsern abhängig.
Der Hochkant-Parameter dient dazu, stark querformatige oder Wolkenkratzer-Bilder in der Basis-Darstellung besser zu präsentieren. Daraus ein Gefrickel zu machen, wie sich die Bildlegende in der Seite präsentieren solle, ist eine missbräuchliche Spielerei. Die eigentliche Aufgabe des Hochkant-Parameters, nämlich das geeignete Seitenverhältnis, wird lediglich von der ersten Dezimalstelle gesteuert (siehe oben: For caching health: If width scaled down due to upright parameter, round to full __0 pixel to avoid the creation of a lot of odd thumbs.)
Nichts von all diesen Basteleien wird über die Jahre Bestand haben, weil es keine Anforderung an irgendeine Software gibt, diese pixelgenauen Rechnereien unterstützen zu müssen oder gar zu garantieren. Sie sind deshalb absolut wertlos und führen nur zu überflüssiger Beschäftigung der Bearbeiter und vergeuden die Zeit der Autoren.

VG --PerfektesChaos 13:56, 9. Mai 2018 (CEST)

Aber so was von +1. Wer sich mit solchen merkbefreiten Kinkerlitzchen tatsächlich beschäftigt, sollte dieses absurde Tun dringend überdenken. Grüße vom Sänger ♫ ^(Reden) 14:04, 9. Mai 2018 (CEST)

@PerfektesChaos @Benutzer:Sänger: ich (und auch Raymond) raten dem Benutzer Kim117 nicht zu seiner Formatierungsmethode zu. Warum man ihm aber unter Heranziehung von Extremwerten (1.0 → 1.03) sinnfreies Arbeiten vor den Kopf knallt und dann auch noch ein praktisch geschrienes +1 hinterher kommt, ist mir nicht begreiflich. Ohne eueren Auftritt wäre es sicher auch gegangen. --Summer • Streicheln • ~~Note~~ 14:24, 9. Mai 2018 (CEST)

Damit kein Missverständnis entsteht: habe zwei Nachkommastellen nur in einigen Sonderfällen, wie bei obigem Bild mit Übergröße, verwendet. Ansonsten habe ich bei Bildern mit dem Parameter hochkant allermeist überhaupt keinen Zusatz gemacht. Vielleicht beruhte die ganze Diskussion nur auf diesem Irrtum, da ich mich zu wenig deutlich ausgedrückt habe. Grüße --Kim117 (Diskussion) 11:29, 10. Mai 2018 (CEST)

Hi Kim117, wir haben es hier mit zwei Dingen zu tun, die etwas durcheinander gelaufen sind.

1. dein Versuch, Zeilenumbrüche in der Bildunterschrift durch die Bildbreite zu steuern ist nicht sinnlos ... wird aber nicht immer und überall den gewünschten Effekt haben. Siehe z.B. mein 'Brillenargument' weiter oben (deine Tests werden korrekt sein - deine Methode wird aber oft nicht funktionieren wobei 'oft' eine schwer zu definierende Variable ist). Wäre hier etwas ruhigeres Fahrwasser, dann könnte man vernünftig besprechen wie du deinem Ziel trotzdem sehr nahe kommst (wird auch in der Praxis gemacht - aber eher intuitiv). Du gibst alle Zeilenumbrüche der Bildunterschrift per <br> vor und wählst die Zeilenlänge manuell genügend kurz. So kurz, dass sie bei allen vernünftigen Schriftgrößen/-arten nicht noch zusätzlich durch den Brower umgebrochen werden. Intuitiv wird das gelegentlich gemacht, wenn z.B. unter einer Grafik eine Farblegende mit kurzen Zeilen steht. Lässt sich leider nicht ganz einfach beschreiben ... (selten mach ich das selbst und wir können uns gerne auf einer Artikeldisk am konkreten Beispiel besprechen). Man muss aber bei all dem Wissen - man Erhöht durch diese Tricks nur die Wahrscheinlichkeit, das die Umbrüche wie gewünscht dargestellt werden (wenn z.B. ein Benutzer eine Bildbreite von 150px in seinen per. Einstellungen hat, ist dagegen kein Kraut gewachsen).

Noch ein Tipp den du bei 'Sonderformatierung' immer beachten solltest: stell als Test unterschiedlich Wert für die Standartgröße der Vorschaubilder ein ... da fällt die schlechte Formatierung sofort ins Auge.

2. Das zweite Thema ist die Wirkung des Parameter 'Hochkant'. Diesen Parameter als exakte 'Zeilenumbruchshilfe' einzusetzen wird nicht für jeden Brower (Schriftart etc.) funktionieren (als grobe Zeilenumbruchshilfe schon - s.o.). Es ist aber ein toller Parameter um das gesamte Layout zu beeinflussen. Ich erklär nochmal was Raymond (der Programmierer des Hochkantparameters) schrieb: er nimmt den Basiswert der Bildbreite (den Wert aus Einstellungen -> Aussehen -> Standardgröße der Vorschaubilder: - der Standard ist 220px) und multipliziert es mit dem Wert des Parameter 'Hochkant' und verwendet das Ergebnis als neue Bildbreite. Am Ende rundet er noch Bildbreite auf 10px (das ist zur Minderung der Serverlast sehr vernünftig!). Zwei Rechenbeispiele: mit Hochkant 1.0' und 1.1': 220px*1.0=220px; 220px*1.1=242px gerundet 240px. Da der Unterschied zwischen 1.0 und 1.1 ein Zehntel, also 10% beträgt, findet man im Ergebnis auch rund 10% (hier 20px) Unterschied wieder. Raymonds Programm erlaubt aber 10px statt nur 20px! Und wenn du es mit dem Hochkantwert 1.03 durchrechnest (also genau der Wert, den PerfektesChaos oben als sinnfreie Fummelei abtut), dann siehst du, das es gerundete 230px ergibt - man füllt also genau die Lücke von 20px, die zwischen den Hochkantwerten 1.0 und 1.1 liegt. Wem Rechnen nicht so liegt, der kann es auf meiner Ben. bei commons anschauen (siehe dortiges Zitronenbild).

Vereinfacht gesagt: verwendet man nur die erste Stelle hinter dem Komma, macht man 20px Sprünge, verwendet man die zweite Stelle hinterm Komma, macht man 10px Sprünge. Sicher kann man Streiten, ob 10px Sprünge gegenüber 20px Sprüngen sinnvoll sind - vor dem Diskutieren über dem Sinn kommt aber das darstellen der Fakten. Ich persönlich würde dir empfehlen, die zweite Nachkommastelle zu benutzen wenn das Ergebnis bei bloßem Ausprobieren gut aussieht (ich könnte das noch genauer begründen - aber das würde den Rahmen sprengen). Um es nur kurz anzureißen: wer in seinen pers. Einstellungen 400px als Basiswert hat, macht bei der ersten Nachkommastelle 40px Sprünge statt möglichen 10px Sprüngen mit der zweiten Nachkommastelle (Daumenbreite statt Buchstabenbreite) ... das ist dann kein Peanuts mehr.

Aber ganz sicher kannst du dich darauf verlassen, das Raymonds Programm deinen Parameter vernünftig auswertet - selbst wenn du zehn Stellen hinter dem Komma angibst. Und du musst dich nicht rechtfertigen, ob und wie oft du die zweite Nachkommastelle benutzt.

3. nochmal angemerkt: der Ton gefällt mir hier überhaupt nicht. Ganz oben wurde ich mit RTFM (Read the fucking manual; zur Erinnerung - das 'Handbuch' war vor meiner Korrektur nachweislich falsch!) als dummer Junge hingestellt und das gipfelt nun hier im Geschreie vom Sänger. Spart euch das!!! Nach meinem dafür knallt man Benutzern auch nicht eine Methode als Unsinn vor den Latz sondern erklärt warum. Und dazu gehört nun mal, die vermeidlich unsinnigen Herangehensweisen zu besprechen. --Summer • Streicheln • ~~Note~~ 15:50, 10. Mai 2018 (CEST)

Vielen Dank für Deine ausführliche Erklärung. Zu obigem linken Bild habe ich mal statt dem Parameter 'hochkant' px benutzt. Bei 345px gab es bei mir in allen Schriftgrößen-Einstellungen das gewünschte, selbe Ergebnis, mit 3 Zeilen auf kleinst möglichem Raum. Während bei 344px die Bildlegende auf 5 Zeilen umsprang. Brächte die Verwendung von px gegenüber dem Parameter 'hochkant' irgendwelche Vorteile? Vermutlich nach Deiner Erläuterung nicht. --Kim117 (Diskussion) 17:46, 10. Mai 2018 (CEST)

Junta Departamental de Montevideo (Bauwerk)

wird bei mir falsch angezeigt (gedreht um 90°)--Wheeke (Diskussion) 08:17, 21. Sep. 2018 (CEST)

Bei mir nur teilweise, sowohl IE11 und FF52 unter Win7, als auch DuckDuckGo und Chrome unter Android 8 zeigen das richtig. Die App auf dem Wischhandy kann sich allerdings nicht einigen: Unten im Artikel selber wird es liegend, oben in dem üblichen Vorschaubild korrekt ausgerichtet angezeigt. Grüße vom Sänger ♫ ^(Reden) 09:44, 21. Sep. 2018 (CEST)

Sieht bei mir normal aus, allerdings wurde das Bild →mal gedreht, vermutlich eine alte Serverversion.

Bitte auch das Intro dieser Seite beachten, deine Anfrage hat nicht wirklich etwas mit der „Gestaltung der Seite Hilfe:Bilder“ zu tun. --Liebe Grüße, Lómelinde Diskussion 10:03, 21. Sep. 2018 (CEST)

Das ist freilich richtig. An welche Hilfeseite kann ich mich denn bitte wg solches Problems wenden?--Wheeke (Diskussion) 10:17, 21. Sep. 2018 (CEST)

Vermutlich WP:FZW. Grüße vom Sänger ♫ ^(Reden) 10:19, 21. Sep. 2018 (CEST)

Steht im Intro: „Fragen zum Hochladen oder Sonstigem können in der Wikipedia:Redaktion Bilder […]“

Gegenfrage ist es noch immer gedreht? Ich habe den Artikel eben mal bearbeitet, um den Server anzustoßen. --Liebe Grüße, Lómelinde Diskussion 10:23, 21. Sep. 2018 (CEST)

In der App noch immer, sonst wie gehabt. Grüße vom Sänger ♫ ^(Reden) 10:28, 21. Sep. 2018 (CEST)

Immer noch gedreht, firefox. --Wheeke (Diskussion) 11:05, 21. Sep. 2018 (CEST)

Bei mir auch Firefox und Win7. Alles normal, aber gestern war Softwareupdatetag. Vielleicht haben die etwas im Bereich Bilder umgebogen. --Liebe Grüße, Lómelinde Diskussion 11:10, 21. Sep. 2018 (CEST)

Noch eine Nachfrage, ist bei dir der Medienbetrachter aktiviert? Ich habe zwar auch das getestet, und bei mir sieht alles normal aus, aber da diese Frage hier Wikipedia:Fragen zur Wikipedia#Schwarzer Bildschirm auch gerade hereinkam scheint doch irgendetwas geändert worden zu sein. --Liebe Grüße, Lómelinde Diskussion 11:13, 21. Sep. 2018 (CEST)

Diese Bilddatei hat einen Knacks, den sie sich zugezogen hatte, als sie früher mal gedreht wurde. Dabei wurden Fehler gemacht, das ist bekannt. Manche Darstellungswerkzeuge berücksichtigen die halbfertige Drehung, manche ignorieren den Versuch. Auf Commons erörtern, hier absolut falsch. LG --PerfektesChaos 12:06, 21. Sep. 2018 (CEST)

Habe nun das aus es: rüberkopiert mit den Formatierungen. steht zwar jetzt richtig. dennoch bleibt der Wurm drin--Wheeke (Diskussion) 13:55, 21. Sep. 2018 (CEST)

Benutzer:Steinsplitter hat bei dem Bild im Jan. 2017 das EXIF Rotation-Flag von 6 auf 1 gesetzt (ist zumindest etwas ungewöhnliches). Er sollte daher informiert sein was hiermit geschehen ist. --Summer • Streicheln • ~~Note~~ 07:54, 26. Sep. 2018 (CEST)

Einbindung von Panoramabildern

Auf der Vorderseite ist im Abschnitt "Panoramabilder" zu lesen, das Bild solle nie größer werden als die Breite der Druckversion (ca. 780px). Heißt das, dass in der Vorlage {{Panorama}} die Bildgesamtbreite höchstens mit 780 angegeben werden soll? Ist mir neu, wird in der Vorlagendokumentation nicht erwähnt und mannigfach anders gehandhabt. Es wird aber in Diskussion:Blauen (Badenweiler)#Illustration von meinem Gegenüber behauptet. --Milseburg (Diskussion) 20:34, 30. Okt. 2018 (CET)

So wie ich das sehe, bezieht sich das 780px auf Panoramabilder (Bilder mit Breite viel größer als Höhe), die über die normale Bild-Syntax eingebunden werden. Ein breites Bild ist dann häufig breiter als das Browserfenster und erzeugt ein Scrollbalken am Browserfenster. Beispiel mit 1000px:

Die {{Panorama}} ist eine Möglichkeit Panoramabilder breiter einzubinden. Der Scrollbalken erscheint dann hier am Bild selbst und nicht am Browserfenster. Beispiel mit 1000px:

vergrößern und Informationen zum Bild anzeigen

Blick von der Terrasse des Blauenhauses nach Süden auf die Alpenkette.

--Fomafix (Diskussion) 10:56, 31. Okt. 2018 (CET)

Fomafix: du solltest bei deinem Bsp. mit 1000px noch ne Schippe drauf legen ... sonst verstehen dich Leute, die einen breiten Bildschirm haben nur schwer. --Summer • Streicheln • ~~Note~~ 11:58, 31. Okt. 2018 (CET)

Hier das gleiche Beispiel mit 1500px:

Bild-Syntax:

{{Panorama}}:

vergrößern und Informationen zum Bild anzeigen

Blick von der Terrasse des Blauenhauses nach Süden auf die Alpenkette.

--Fomafix (Diskussion) 12:13, 31. Okt. 2018 (CET)

Danke für die Info. Ich verstehe. Allerdings habe ich wohl einen sehr breiten Bildschirm. Bei 1500px sehe ich auch keinen Unterschied. Ab 2000px wird es aber deutlich. Ich schlage vor, dass auf der Vorderseite klarer formuliert wird, dass die 780px nicht der Maximalwert für die Angabe der Bildschirmbreite in der Vorlage Panorama sind. Sonst fangen manche User an, die Werte überall herabzusetzen, wo die Vorlage Panorama verwendet wird. --Milseburg (Diskussion) 15:53, 31. Okt. 2018 (CET)

Die 780px hat Benutzer:W!B: am 2. Mai 2006 eingebracht. Damit sah die Seite so aus. Das damalige Beispiel mit div-Einbindung nahm 2000px als Bildbreite und nicht etwa 780. Die Vorlage:Panorama gab es zu dem Zeitpunkt noch gar nicht. --Sitacuisses (Diskussion) 07:46, 1. Nov. 2018 (CET)

Es ist auf jeden Fall nicht sinnvoll, die Pixelbreite über 780px hinaus zu vergrößern weil man damit in Kauf nimmt, dass ein Scrollbalken auftaucht. Gerade wenn man auch nur auf 1000px geht so fehlen oft nur 10-20% der Bildbreite je nach Einstellung und das ist weder nötig noch zielführend. Sofern ein Bild tatsächlich so ein extremes Bildverhältnis zwischen Höhe und Breite hat, dass man mit 780px nicht hinkommt weil alles zu klein wird, muss man das Bild entweder aus dem Artikel raus lassen oder aber auf eine entsprechend hohe Pixel-Zahl setzen. Ein Scrollbalken macht nur dann wirklich Sinn wenn man auch einen entsprechend großen Bereich des Bildes damit abfahren kann. Alles andere ist nur nervig. --Alabasterstein (Diskussion) 09:23, 1. Nov. 2018 (CET)

Von welcher der zahlreichen heute üblichen, sehr unterschiedlichen Bildschirmauflösungen vom Smartphone bis zum Großmonitor gehst du gerade aus? Inwiefern schlägt sich die Entwicklung der letzten mehr als 12 Jahre in deiner Einlassung nieder? Und welcher deiner Sätze gilt: "Es ist auf jeden Fall nicht sinnvoll, die Pixelbreite über 780px hinaus zu vergrößern" oder "muss man das Bild [...] auf eine entsprechend hohe Pixel-Zahl setzen"? --Sitacuisses (Diskussion) 14:06, 1. Nov. 2018 (CET)

Hättest du meinen Beitrag auf der Diskussionsseite des Artikels aufmerksam gelesen, müsstest du diese Frage nicht stellen. Es ist auch nicht primär eine Sache der Auflösung. --Alabasterstein (Diskussion) 14:26, 1. Nov. 2018 (CET)

Ich habe dir heute schon viel zu viel Aufmerksamkeit geschenkt und bin zum Ergebnis gekommen, dass du nicht weißt wovon du sprichst und das durch Anblaffen deiner Gesprächspartner kompensieren möchtest, was naturgemäß nicht funktioniert. --Sitacuisses (Diskussion) 16:08, 1. Nov. 2018 (CET)

Dann frag nicht wenn du dich damit nicht auseinander setzen willst. Und: wie es in den Wald reinschallt, so schallt es auch heraus. Also erspar uns bitte diese gemiemte Diskussionsbereitschaft gleich ganz. --Alabasterstein (Diskussion) 16:13, 1. Nov. 2018 (CET)

Wer eine 'Überbreite' (als Bsp. mal 1.500px) so einbinden möchte, das sie die Bildschrimbreite optimal ausnutzt ohne am Browserfenster einen Scrollbalken zu erzwingen hat zwei Optionen:

Will er, das Detail erkennbar sind, dann muss er die Vorlage Panorama nehmen. Gibt er in der Panoramavorlage eine Breite von 1.500px an, dann erscheint das Bild detailreich. Auf Browserfenstern mit eine Nettobreite bis 1.500px hat das Bild einen Scrollbalken. Sollte das Browserfenster mehr als eine Nettobreite zur Verfügung stellen, werden die Ränder weiß aufgefüllt. Die Detailtreue bleibt bei allen Fenstergrößen gleich.
Wenn es auf die Detailtreue nicht ankommt, dann muss man die Technik einsetzten, die im Abschnitt „Breites Bild via gallery“ beschrieben ist (habe ich mal eingebaut). Mit der Technik wird auf Detailtreue immer gepfiffen, aber die Nettobreite wird immer optimal ausgenutzt.

Alles andere (feste Pixelbreiten, Parameter Hochkant) ist Murks! --Summer • Streicheln • ~~Note~~ 16:37, 1. Nov. 2018 (CET)

Danke, Sitacuisses, dass du W!Bs Edit von 2006 ausgegraben hast. Wenn man vergleicht, was damals gemeint war und heute dasteht, ist die aktuelle Fassung sinnentstellt. Der Trick, von dem W!B damals sprach ist ja heute die Vorlage Panorama. Daher als Formulierungsvorschlag: "Panoramabilder einzubinden ist immer eine gewisse Herausforderung. Grund dafür ist, dass die Größe des Browser-Fensters des Lesers nicht direkt ermittelt werden kann: Also sollte das Bild nie größer werden als die Breite der Druckversion (ca. 780px). Um breitere Bilder einzubinden sollen die Vorlagen {{Panorama}} und {{Große Imagemap}} verwendet werden." Von mir aus, kann das mit den 780px auch ganz raus. Ob die Vorlage "Große Imagemap" noch aktuell ist, weiß ich gar nicht. Ich habe die noch nie verwendet. Stattdessen begegnet mir seit einigen Jahren zum Einbinden von Panoramen auch die Galerie "packed" wie etwa bspw. hier: Sackpfeife (Berg)#Lage. Ich weiß da nie so genau, welche Art der Einbindung ich da nehmen soll. Ich würde es begrüßen, wenn auch dazu mal etwas Erhellendes auf der Vorderseite gesagt werden könnte. --Milseburg (Diskussion) 16:39, 1. Nov. 2018 (CET)

Quetsch als Info: die Sackpfeife wurde hier auf gallery umgestellt. --Summer • Streicheln • ~~Note~~ 17:09, 1. Nov. 2018 (CET)

Anmerkung: Die Einbindung des Panoramas in Sackpfeife wurde wurde heute von Benutzer:Antonsusi verändert. Ich weiß nicht, ob er diese Disk. kennt. Jedenfalls ist jetzt nur noch in älteren Versionen der Sackpfeife erkennbar, was ich gemeint habe. Ein mit der Galeriefunktion eingebundenes Panorama sieht man bspw. aktuell auch hier: Katinger Watt#Panorama --Milseburg (Diskussion) 13:45, 4. Nov. 2018 (CET).

Unter Spezial:Weiterleitung/revision/180996187#Lage bleibt die alte/mittlere Sackpfeife selbstverständlich verfügbar. --Diwas (Diskussion) 00:41, 5. Nov. 2018 (CET)

Wie das mit den 780px damals gemeint war oder nicht mag historisch interessant sein. Das Problem wird damit nicht beseitigt. Scrollbalken sind gem. der Barrierefreiheit ganz zu vermeiden. Das gilt nicht nur für Bilder sondern auch für Tabellen mit einer gewissen Überbreite. Diese kann zwar nicht immer vermieden werden. Aber der Grundsatz sagt: es ist generell darauf zu achten und wo möglich zu vermeiden [1]. Wenn nun ein Bild mit 1000px einen Scrollbalken erzeugt dann sind diese 1000px nicht sonderlich weit von den 780px entfernt. Das bedeutet dann für das Bild auch kaum eine merkliche Verkleinerung bei gleichzeitiger Vermeidung der Vorlage Panorama bzw. wenn man sie verwendet und auf diesen Wert setzt dann entsteht dennoch kein Scrollbalken. Da die Anforderungen für die Barrierefreiheit sicherlich mal umfassender gilt als die Vereinbarungen für Bilder sollten selbstverständlich auch bei der Darstellung der Bilder darauf geachtet werden. --Alabasterstein (Diskussion) 17:02, 1. Nov. 2018 (CET)

Das von Milseburg zitierte Beispiel mit Sackpfeife (Berg)#Lage finde ich übrigens ausgesprochen gut und sauber in der Darstellung. --Alabasterstein (Diskussion) 17:05, 1. Nov. 2018 (CET)

Und selbst für 360-Grad-Panorama-Aufnahmen reicht eine Pixelbreite von "um die 800 Pixel" völlig aus, wie das Bild in diesem Abschnitt Eiffelturm#Dritte_Etage_und_Turmspitze zeigt. Die Bildwirkung wird auch in dieser kleinen Darstellung erfasst. Und niemand wird daran gehindert, in das Bild reinzuklicken und es auch in der vollständigen Auflösung zu betrachten. Aber das Bild nun auf 1000px oder 1500px zu strecken bringt (a) nur den unerwünschten Scrollbalken (b) macht den Gesamteindruck des Bildes zunichte weil es faktisch abgeschnitten wird und man gezwungen ist, zu scrollen und ist (c) auch nicht so groß, dass die Menschen, die sich das Bild gerne genauer betrachten würde damit befriedigt wären. Also ich erkenne darin wirklich keinen Nutzen oder Mehrwert. --Alabasterstein (Diskussion) 17:11, 1. Nov. 2018 (CET)

Mit Alabasterstein kann man sicher auch eine Löschdiskussion über die Vorlage Panorama führen. Ich verstehe en-WP zur Barierefreiheit durchaus so, dass horizontales Scrollen zulässig ist, wenn es nicht übermäßig ist. Und die Vorlage Panorama ermöglicht genau das. Man scrollt nur beim Bild und nicht beim ganzen Artikel. Ich finde durchaus, dass die Bildwirkung eines Panoramas leidet, wenn es nur noch als winziger Streifen dargestellt wird. Das kann nicht besser sein, besonders nicht für Menschen mit Sehbehinderung. Ich fand auf de-WP dazu bisher keinen Konsens. --Milseburg (Diskussion) 17:56, 1. Nov. 2018 (CET)

Wenn die Bildwirkung eines Panoramas schlecht ist obwohl es die gesamte Standard-Artikelbreite zur Verfügung hat dann ist es nichts weiter als ein schlechtes Bild und durch die parametrisierbare Breiteneinstellung auch nicht verbesserbar.

Details kann man auch bei Verdoppelung der Bildbreite nicht wirklich erkennen, so dass der Mehrwert nicht wirklich hinreichend begründet wird. Wenn ich mich bei einem Panorama, welches 25000x6000 Pixel misst (und solche Panoramas sind heutzutage auch keine Seltenheit mehr) für Details interessiere bin ich auch dann gezwungen, in die 100%-Ansicht zu wechseln auch wenn ich dem Bild in der Panorama-Funktion eine Bildbreite von 5000px zubillige. Horizontales Scrollen ist horizontales Scrollen, ob ich das am Artikel oder am Bild mache ändert nichts daran, dass Menschen mit Beeinträchtigungen das Erfassen unnötig erschwert wird. --Alabasterstein (Diskussion) 08:22, 2. Nov. 2018 (CET)

Dieses Pauschalurteil ist eine Beleidigung all der Artikelbearbeiter, die Panoramen entsprechend ihres Bildinhaltes in Artikel einbauen. Es ist auch in sich nicht schlüssig, denn wenn die Panoramen, wie du meinst, eh nichts erkennen lassen, kann den Benutzern mit Beinträchtigung das Scrollen auch egal sein. Im übrigen habe ich den Eindruck, dass du noch nie eine Wikipedia-Seite auf einem Mobilgerät angeschaut hast, sonst würdest du nicht so viel von Scrollen reden. Versuche bitte wieder aus dem Geisterfahrer-Modus rauszukommen und konstruktiv mitzuarbeiten, das führt sonst zu nichts Gutem. --Sitacuisses (Diskussion) 08:59, 2. Nov. 2018 (CET)

Dieses Panoramagedöns sollte aus Artikeln fernbleiben. Fotos, die als Vorschaubild nichts erkennen lassen, haben nichts in Artikeln zu suchen. Und Bilder, die man nur mit Sondersoftware angucken kann, sind völlig fehl am platz. --M@rcela

11:31, 2. Nov. 2018 (CET)

Die Aussage „Und Bilder, die man nur mit Sondersoftware angucken kann, sind völlig fehl am platz“ kann ich zu 100% unterstützen. Hat dummerweise aber mit dieser Diskussion nichts zu tun weil der Benutzer bei Panoramabildern keine Sondersoftware einsetzen muss. --Summer • Streicheln • ~~Note~~ PS: mich stören Signaturen, die mit den Namen in der Versionsgeschichte in keinerlei Zusammenhang stehen. Macht Dritten nur unnötig Arbeit Diskussionen zu verfolgen ...

Es müßte erstmal geklärt werden, was mit Panoramaaufnahmen eigentlich gemeit ist. Da kommen mehrere Fälle in Frage:

Kugelpanoramen oder Ähnliches, dazu braucht man Spezialsoftware, sonst sind die Ansichten ziemlich sinnlos.
Bilder mit großem horizontalem Erfassungswinkel - kann man nicht pauschal einordnen, dieses Bild hat knapp 270° horizontal, ist als normales Vorschaubild brauchbar
Schlauchbilder mit wesentlich mehr Ausdehnung horizontal als vertikal - das muß aber nicht zwingend ein Panorama sein.

Letztere bieten nur begrenzt Aussagekraft. Egal, wie man sie einbindet, bereiten sie immer irgendwelche Probleme. Der Mehrwert hält sich in Grenzen. --M@rcela

18:13, 2. Nov. 2018 (CET)

Das ist eine Frage der Seitenverhältnisse, zu denen Summer sich weiter unten schon ausführlich ausgelassen hat. Ich muss dir widersprechen. Wenn es um Aussichten (Berge, Türme) oder Übersichten (Landschaften) geht, besitzen eigentlich nur Bilder mit extremem Seitenverhältnis genügend Aussagekraft, z.B. Rimberg (Hinterland).--Milseburg (Diskussion) 18:26, 2. Nov. 2018 (CET)

Neeeiiinnn, muss man nicht vorher klären! Aus dem Kontext geht hervor, das mit Panoramabilder alles gemeint ist, das viel breiter als hoch ist und auf dem man die Dinge erkennen kann ohne die Augen zu verdrehen (was denn beispielsweise bei Kugelpan. im Rohformat der Fall wäre). Meinetwegen kannst du das Bild eines Turms, das viel höher als breit ist gerne als (Sonderfall oder auch nicht) Panorama bezeichnen. In dieser Diskussion gehen wir vom ganz einfachen Fall aus. Einfach weil einfach einfach ist. --Summer • Streicheln • ~~Note~~ 18:32, 2. Nov. 2018 (CET)

Sitacuisses: welche meiner Aussagen wertest du als Pauschalurteil? Darin bleibst du unklar. Sehr wohl lese ich Wikipedia auch mobil. Dein Eindruck ist folglich falsch. Editieren mit mobilen Endgeräten (bis auf Kleinigkeiten) ist mir freilich zu fummelig. Kenne aber auch niemanden, der größere Änderungen am Artikel an seinem Handy ausführt. Aber das ist leider auch nicht wirklich zielführend, weil die Barrierefreiheit ganz grundsätzlich mal für alle Endgeräte zu gelten hat. Dass man das nicht immer erfüllen kann ist klar. Hier aber haben wir es gleich mit mehreren Möglichkeiten zu tun, wie man Panoramen einbinden kann und dann ist es sicher mal legitim über die Möglichkeit zu diskutieren, die gewisse Probleme schafft. Bitte unterlasse Unterstellungen wie "Geisterfahrermodus" und "nicht konstruktiv", denn ansonsten muss ich davon ausgehen, dass in Ermangelung von Sachargumente du dich in persönliche Frotzeleien flüchtest, was ich bei dir aber generell oft beobachtet habe. --Alabasterstein (Diskussion) 12:17, 2. Nov. 2018 (CET)

Die Bedenken im Zusammenhang mit der Barrierefreiheit sind nicht neu und wurden bei der Löschdiskussion zur Vorlage {{Panorama}} 2010 schon durchgekaut und zurückgewiesen. Der Löschantrag wurde abgelehnt, die Vorlage blieb und wird auch vielfach genutzt. Das brauchen wir hier nicht zu wiederholen. Mich würde eher eine Verbesserung der Formulierung auf der Vorderseite interessieren und was es zur Vorlage {{Große Imagemap}} und zu der Galeri-Alternative (s.o.) zu sagen gibt. Der Aufguss-Diskussion blendet das aus. PS: Wieso es für Menschen mit Beeiträchtigung besser sein soll, wenn man etwas kleiner macht, habe ich noch nicht verstanden. --Milseburg (Diskussion) 14:28, 2. Nov. 2018 (CET)

Zur Barrierefreiheit: ich finde es sehr gut, das hier an selbige gedacht wurde. Weil genau das, also das 'im Hinterkopf behalten', wichtig ist. Daran Denken ist allerdings nicht mit darüber Diskutieren gleichzusetzen! Ohne jede Frage stellt die Vorlage Panorama für manche Menschen ein Barriere da. Auf der anderen Seite ermöglicht sie vielen Menschen "Blicke", die sie ohne die Vorlage nicht hätten. Der Gedankenlose Einsatz sollte entsprechend vermieden, der sinnvolle Einsatz durchgeführt werden. Das daran Denken ist das alles Entscheidende. Und leider leider geht Barrierefreiheit den Meisten Kollegen mehr als am Arsch vorbei.

Zu „Mich würde eher eine Verbesserung der Formulierung auf der Vorderseite interessieren und was es zur Vorlage {{Große Imagemap}} und zu der Galeri-Alternative (s.o.) zu sagen gibt“ (Zitat Milsbhrg): Auf Große Imagemap würde ich nicht weiter eingehen wollen. Das ist meines Erachtens eine Erweiterung der Vorlage Panorama mit Spielereien (Hier sind alle Einbindungen gelistet ... also so gut wie keine ... es gibt keine erkennbaren Vorteile, nur Nachteile für die Barrierefreiheit und das Ding sollte verschwinden).

Bleiben noch die Vorlage Panorama und die Gallerie-Technik. Als ich die Gallerie-Technik 2015/16 beschrieb, [2],[https:// de.wikipedia.org/w/index.php?title=Hilfe:Bilder&diff=153004150&oldid=152078810] hatte ich fast keine Hoffnung das sie auf der Seite bestand hat. Deshalb hielt ich den Aufwand in Grenzen.

Ein verbesserter Text sollte zwei Teile enthalten. Einen beschreibenden Teil, wie die Techniken jeweils angewandt werden. Also beispielsweise die Funktion der Parameter (das steht schon weitgehende da).

Als zweites sollte eine Empfehlung rein, wann welche Technik sinnvoll ist. Oben (1. Nov. 2018 16:37 Uhr) habe ich einen wichtigen Aspket aufgeschrieben, wann welcher Technik der Vorzug zu geben ist. Oben ging es um den Aspekt, ob es mehr auf den Überblick oder Detail ankommt.

Es gibt noch einen zweiten Aspekt, der für die Entscheidung wichtig ist. Milseburg hat das oben mit „winziger Streifen“ beschrieben. Dazu ein fiktives Beispiel: wenn ich mehrere Kilometer der chinesischen Mauer abfotografiere und durch Stichen ein Panorama erzeuge, erhalte ich ein sehr sehr breites Bild mit kaum Höhe. Als ganzes auf einem Bildschirm dargestellt, ergäbe es eine haardünne Linie. In dem Fall wäre die einzig sinnvolle Darstellung in wählbaren Ausschnitten - genau das macht die Panoramavorlage ja.

Für die Technik mit Gallerie gibt es also offenbar ein Band von sinnvollen Seitenverhältnissen. Hier habe ich mal ein paar Seitenverhältnisse aufgelistet.

c:File:Panorama Schwerin Wasserturm Neumuehle.jpg: umseitig als Bsp. verwendet. Seitenverhältnis 11.070 / 852 = 12,992
c:File:PanoBlauen-IMG 6623-6637 900.jpg: in dieser Disk. als Bsp. (bzw im Artikel Blauen (Badenweiler)) verwendet. Seitenverhältnis 6962 / 900 = 7,735
c:File:Sackpfeifen-Vorhöhen.jpg: in dieser Disk. als Bsp. verwendet. Seitenverhältnis 2.591 / 485 = 5,342
c:File:Panorama von der Milseburg.jpg: in Milseburg verwendet. Seitenverhältnis 15.922 / 2.000 = 7,961
c:File:Forestry Forwarder Ösa 250 2.jpg: Bsp. für sehr breitformatiges Foto auf Vorderseite Seitenverhältnis 4.000 / 1.640 = 2,439

Ich würde sagen, das Seitenverhältnisse von etwa 4 bis 7,5 sinnvoll mit der Gallerie-Technik dargestellt werden können. die Vorlage Panorama macht etwa von 5,5 bis unendlich Sinn. Und unterhalb von 4 ist konventionelle Einbindung angezeigt (normale Bilder haben nebenbei ein Seitenverhältnis von 4:3=1,333 bis 3:2=1,5). Das wären nur grobe Richtwerte. Das Argument mit der Detailansicht oben bliebe.

Diese Grafik hat übrigens eine Seitenverhältnis von 6.000 zu 400 - also sage und schreiben 15! Und sie ist in Türkische Lira#Inflation sinnvoll eingebunden. Und wird sogar per Bot täglich aktualisiert. Die Vorlage Panorama kann also durchaus Sinn machen. --Summer • Streicheln • ~~Note~~ 16:47, 2. Nov. 2018 (CET)

Danke für deine Erläuterungen, Summer. Ich möchte dich ermuntern, sie auch auf der Vorderseite umzusetzen. Ich denke, die {{Große Imagemap}} kann raus. --Milseburg (Diskussion) 18:33, 2. Nov. 2018 (CET)

ich wollte nur anmerken: ja, mein hinweis datiert mitte 2000er, da kamen die 1800+-px-bildschirme gerade erst auf. heutzutage muss man einen kompromiss irgendwo zwischen smartphone und 4000px-breitleinwand finden. und in ein paar jahren siehts sowieso wieder ganz anders aus. inwieweit die DINA4-druckversion (~800px) heute noch als layout-standard gelten kann, fragt sich insgesamt: für infoboxen (max ~330px) und ähnliches gilt er noch. und für die 180px-standard-thumbs auch. und zu der zeit (2006) waren auch kaum sinnvolle panoramen in heutiger dimension machbar --W!B: (Diskussion) 09:59, 5. Nov. 2018 (CET)

Der Standardwert für Vorschaubilder wurde vor einigen Jahren auf 220px angehoben. Grüße --Diwas (Diskussion) 23:07, 5. Nov. 2018 (CET)

Grosses Bild auch ohne JavaScript auf Fensterbreite formatieren

Wie bekommt man ein sehr breites Bild so eingebunden, dass es (nicht vom Server, sondern vom Browser) auf Fensterbreite skaliert (reduziert) wird ? Ohne Wikisyntax wuerde man wohl ein HTML-Element etwa mit width=99% verwenden.
Das auf dieser Hilfeseite beschriebene Verfahren mit Galerie funktioniert nur mit aktiviertem JavaScript - ohne erscheinen Scrollbalken.
Hier wurde mir nicht geholfen. -- Juergen 217.61.192.157 06:53, 12. Jun. 2019 (CEST)

Ich verstehe nicht wozu das Bild

so groß sein muss, es gibt doch die Möglichkeit es sich über den Medienbetrachter größer anzusehen. Es sollten keine extram großen Bilder in Artikeln eingebunden werden. Es gibt für sehr breite Bilder die Vorlage {{Panorama}}

aber auch diese arbeitet bei Breitenunterschreitung mit Scrollbalken. --Liebe Grüße, Lómelinde Diskussion 11:29, 12. Jun. 2019 (CEST)

Zu „Ich verstehe nicht wozu das Bild

so groß sein muss, es gibt doch die Möglichkeit es sich über den Medienbetrachter größer anzusehen“. Wenn du schon nicht verstehst das man gerne eine Bild in ausreichender Größe sehen möchte - verstehst du denn wenigstens das 72,5% der Befragten in diesem MB wünschten, das der Medienbetrachter standardmäßig abgeschaltet wird? --Summer • Streicheln • ~~Note~~ • Am 21.03.2019 rettete WMDE die Welt • 15:51, 2. Aug. 2019 (CEST)

Da man IPs nicht anpingen kann und sie vermutlich auch nicht mehr hier vorbei schaut, habe ich (hoffentlich) direkt an der Stelle gelöst wo es angefragt war. Siehe diesen Edit einschliesslich HTML-Kommentar. --Summer • Streicheln • ~~Note~~ • Am 21.03.2019 rettete WMDE die Welt • 15:33, 2. Aug. 2019 (CEST)

Eine ziemlich schlechte Lösung.

die Galeriefunktion dient der Einbindung von Galerien wie ihr Name schon vorgibt
Die Frage hier bezog sich auf eine Größe die immer 100 % der Fensterbreite ausfüllen soll und das ist absolut unpassend für einen Artikel

Vermutlich verstehst eher du hier einiges nicht. Lies bitte mal Hilfe:Galerie und mache dir mal klar wozu die gallery-Tags dienen = wozu man diese verwenden soll. Nicht alles, was man machen kann ist auch so sinnvoll oder erwünscht, ich halte es für suboptimal, die Gallery-Tags zur individuellen Layoutgestaltung zu missbrauchen. Dafür sind sie nicht gesacht! Dass man so etwas machen kann weiß ich ich lösche so etwas auch immer wieder aus Artikeln und binde Bilder auf die für sie vorgesehene Weise ein. Wozu haben wir überhaupt Vorgaben, wenn es niemanden interessiert und herumgemurkst wird was das Zeug hält? Eine Galerie besteht aus mehr als einem Bild. Für große Bilder gibt es die Vorlage Panorama. Und zudem ist es nicht durchgehend 100% = Fensterbreite --Liebe Grüße, Lómelinde Diskussion 16:37, 2. Aug. 2019 (CEST)

Wenn ich für den Artikel Javascript ausschalte, sprengt das Bild ein schmal eingestelltes Fenster und füllt die Breite eines breit eingestellten Fensters nicht aus. Ist das bei euch anders? --Diwas (Diskussion) 03:14, 3. Aug. 2019 (CEST)

Ich sage ja die Lösung ist alles andere als gut, aber wenn es der Summer so vorgibt, der ja scheinbar über allen Regeln und Richtlinien steht, kann man da nichts machen, dann muss solcher Murks halt an die Leser ausgeliefert werden. Das scheint ihn ja nicht zu interessieren. Es wird schon seinen Grund haben weshalb man Einzelbilder nicht in galerien formatiert. --Liebe Grüße, Lómelinde Diskussion 07:44, 3. Aug. 2019 (CEST)

Bilderlose Artikel

Hallo Wikipedia Team! Ich würde gerne zur Wikipedia mit Bildern beitragen. Gibt es irgendeine Kategorie, Liste oder vielleicht sogar Karte mit GPS Punkten von Artikeln die Bilder benötigen? --193.171.152.103 10:37, 1. Aug. 2019 (CEST)

Kategorie:Wikipedia:Bilderwunsch? --Liebe Grüße, Lómelinde Diskussion 10:43, 1. Aug. 2019 (CEST)

Vielen Dank für deine schnelle Antwort, das ist wonach ich gesucht habe. Gibt es zu Kategorie:Wikipedia:Bilderwunsch an bestimmtem Ort auch eine Karte? 45.804 Einträge sind ja wirklich nicht wenig. Und da etwas zu finden das halbwegs in der Nähe liegt ist nicht leicht. --193.171.152.103 07:33, 2. Aug. 2019 (CEST)

Oben rechts bei der Kategorie steht etwas wie Karte, ob das aber funktioniert weiß ich nicht. Vermutlich hat das eine sehr lange Ladezeit, bei so vielen Punkten. --Liebe Grüße, Lómelinde Diskussion 10:41, 2. Aug. 2019 (CEST)

Naja, den ganzen Planeten auf einmal muss ja keiner leerknipsen.

Auf der Kategorie-Seite ist dieses Tool verlinkt.

Dort kannst du die ungefähren Koordinaten vom Marktplatz deines Heimatdorfs eingeben, gucken was in zehn bis zwanzig Kilometer Schönwetter-Wochenend-radelfähiger Umgebung unfotografiert rumsteht, und auf geht’s.

LG --PerfektesChaos 12:19, 2. Aug. 2019 (CEST)

Perfekt! Das ist genau das wonach ich gesucht habe! Danke PerfektesChaos - natürlich auch allen anderen)

--193.171.152.104 13:02, 6. Aug. 2019 (CEST)

Bild wird invers dargestellt

auf Ennio Morricone wird die Signatur invers dargestellt, obwohl es eigentlich ein Bild mit schwarzer Schrift auf durchsichtigem Hintergrund ist = wie kann man das lösen? siehe auch https://commons.wikimedia.org/wiki/File_talk:EM-Signature.png --kai.pedia (Disk.) 15:53, 6. Jul. 2020 (CEST)

Einmal purgen hat geholfen. Gruss --Nightflyer (Diskussion) (ohne (gültigen) Zeitstempel signierter Beitrag von Nightflyer (Diskussion | Beiträge) 16:06, 6. Jul. 2020 (CEST))

Vielleicht lag’s am im Bild gespeicherten Farbprofil? Ich habe eine neue Version hochgeladen, die keine Probleme mehr machen sollte.--Mahlzahn (Diskussion) 16:13, 6. Jul. 2020 (CEST)

Danke! :Archivierung dieses Abschnittes wurde gewünscht von: kai.pedia (Disk.) 14:47, 14. Jul. 2020 (CEST) --kai.pedia (Disk.) 14:47, 14. Jul. 2020 (CEST)

Leerzeilen nach Bildern?

Sind Leerzeilen nach Bildern, wie sie z. B. im Artikel Johann Wolfgang von Goethe vorkommen, notwendig? Sie bedeuten zusätzlichen Speicherplatz und wirken sich – soweit ich weiß – nicht auf die Darstellung aus. --Zaunkoeniglich (Diskussion) 15:51, 24. Nov. 2019 (CET)

Notwendig nicht, aber es erhöht die Quelltextlesbarkeit, wenn nicht alles aneinandergeklatscht wird. Sehr viel Speicherplatz kann das eigentlich nicht verbrauchen. --Liebe Grüße, Lómelinde Diskussion 16:13, 24. Nov. 2019 (CET)

Komische Bildanzeigen?!

Hallo, ich habe in letzter Zeit merkwürdige Probleme bei Bildanzeigen. Sie sind nicht so, wie und wo sie sein sollten.

Bei Cadre-47/1-Weltmeisterschaft_1975 reißt die Vorlage:Absatz eine Riesenlücke zum nächsten Absatz „Turniermodus, indem sie ihn erst am Ende der Infobox beginnen lässt, und ohne „Absatz“ wird der Text an die Galerie rangezogen.
Bei Willie Hoppe ist die Illustration links nicht am richtigen Platz/Abschnitt (Kindheit). Sie soll, wie im Quelltext angegeben, im ersten Absatz gezeigt werden, wo sie ja inhaltlich hingehört.

Wie kommt das? Das Problem hatte ich früher nie. Wurde etwas am align:left geändert? Ist mir echt rätselhaft. Hat jemand eine Idee oder Erklärung dafür? Oder kann es an veränderten Einstellungen an meinem Konto liegen, dass ich ein Tool aktiviert habe, dass da querschießt? Seitdem lädt Wikipedia unter Safari, egal ob ich nur lese oder bearbeite, ewig lange am Seitenaufbau. Dank im Voraus. Gruß Rafael _Nachricht 19:05, 25. Nov. 2019 (CET)

Jedes "Rumbasteln" mit Bildern ist heikel, weil halt jeder Browser, jedes Betriebssystem, jede Fenstergröße und jede Plattform seine Eigenwilligkeiten hat.

Die Vorlage Absatz macht bei mir genau das, was sie sollte: Sie sorgt dafür, dass der Text erst nach allen anderen Einschüben links und rechts fortfährt. Dank Lomelindes Änderung wird das jetzt wohl dargestellt, wie von dir gewünscht: Text fährt nach dem Bild fort dank dem Parameter "links".

Das Bild zur Kindheit erscheint erst dort, weil es zwei Bilder hat, die im Quellcode früher platziert sind. Diese erscheinen rechts nach der Infobox. Das dritte Bild erscheint erst danach, also links auf der Höhe des Zweiten. Das war schon immer so. --Lars (User:Albinfo) 19:52, 25. Nov. 2019 (CET)

Das liegt teilweise an den Infoboxen, die dafür sorgen, dass alle Bilder die rechts stehen erst darunter ausgegeben werden. Ein Bild das dann nach einem Bild rechts folgt wird auch dann weiter nach unten gestellt, wenn es links angeordnet wird, weil das darüber angegebene Bild es mit nach unten zieht. Allerdings solltest du Bilder nicht links eben eingerückte Zitate, Aufzählungen oder Überschriften setzen. Ist es so besser? --Liebe Grüße, Lómelinde Diskussion 19:57, 25. Nov. 2019 (CET)

Ich setze selten Bilder nach links, daher war mir sowohl Absatz|links, als auch die Sortierreihenfolge der Bilder nach den Infoboxen unbekannt. Mal wieder ein bisschen schlauer. Danke euch. Gruß Rafael _Nachricht 20:12, 25. Nov. 2019 (CET)

Eine neue Version dieser Datei hochladen

Wann kommen diese endlich an? Bisher erscheint beim Aufruf die vorherige Version. Nur das Formatverhältnis der neuen Version ist schon da.--Tuvdef (Diskussion) 13:01, 5. Mär. 2020 (CET)
File:24mm-tilt-lens.jpg und File:Front Standard Tilt.png

Dateien mit Crops zu überschreiben ist ganz schlechter Stil. Dass das Bild bei dir nicht richtig angezeigt wird, liegt am Browsercache. --Magnus (Diskussion) 13:10, 5. Mär. 2020 (CET)

Danke, ich habe die Caches meiner Browser jetzt geleert.
Schlechter Stil? WP ist keine Bildergalerie für Fotokünstler (ebenso kein Verlag für die Werke von Schriftstellern). Wir (bei weitem nicht alle in der WP) geben uns endlos Mühe, die Arbeit unserer Vorgänger zu verbessern. Ohne das wäre der Laden sofort einzufrieren.--Tuvdef (Diskussion) 20:57, 5. Mär. 2020 (CET)

Deutlich geänderte Bilder (und damit auch Crops) soll man unter einem neuen Namen hochladen. --Magnus (Diskussion) 08:38, 6. Mär. 2020 (CET)

Das sieht schon ganz anders aua und ist eine Frage der Form, nicht des Stils (Benehmens).--Tuvdef (Diskussion) 11:19, 6. Mär. 2020 (CET)

Bilder aus anderen Sprachräumen

Wie könnten die Wikimedia-Dateien aus anderen Sprachen mit anderen Buchstaben (beispielsweise russisch) eingebunden werden? Gibt es eine Anleitung dafür?
Bsp:

Beispieltext

Beispieltext

funktioniert leider nicht.

Das ist der Originallink. Danke--Wikaz2012 (Diskussion) 14:47, 6. Apr. 2020 (CEST)

Gar nicht, solange sie nicht auf Commons liegen. Bei dem Bild ist das nicht gegeben und auch nicht zulässig. --Magnus (Diskussion) 14:51, 6. Apr. 2020 (CEST)

Verstanden, lieben Dank. Wäre es dann möglich das Bild welches nicht auf Commons, jedoch auf dem Wikiserver liegt (wie in diesem Fall), auf Commons mit den Quellenangaben des ursprünglichen Uploaders hochzuladen?--Wikaz2012 (Diskussion) 20:34, 7. Apr. 2020 (CEST)

Wenn es sich um ein weltweit gemeinfreies Bild handeln würde, dann wäre es über Commons abrufbar. Das scheint hier aber nicht der Fall zu sein. Es gibt lokal unterschiedliche Bestimmungen zum Urheberrecht. In dem ©-Kasten steht in etwa:

„Данный файл является несвободным (не соответствует определению свободного произведения культуры). В соответствии с решением Фонда Викимедиа он может быть использован в русской Википедии только при соблюдении критериев добросовестного использования. Любое другое использование (как в русской Википедии, так и вне её) может стать нарушением авторского права.“

„Diese Datei ist nicht gemeinfrei (entspricht nicht der Definition eines freien Kulturwerks). Gemäß der Entscheidung der Wikimedia Foundation kann es in der russischen Wikipedia nur verwendet werden, wenn die Kriterien für eine faire Verwendung erfüllt sind. Jede andere Verwendung (sowohl in der russischen Wikipedia als auch außerhalb der Wikipedia) kann eine Verletzung des Urheberrechts darstellen.“

Du kannst aber beispielsweise eine Anmerkung Abbildung des Covers<ref>[http://www.close-up.ru/news/detail.php?ID=8769 close-up.ru]</ref> verwenden. Ansonsten frage besser auf der Seite Wikipedia:Urheberrechtsfragen nach, ob es eine andere Möglichkeit gäbe siehe auch Wikipedia:Bildrechte oder Hilfe:FAQ zu Bildern. --Liebe Grüße, Lómelinde Diskussion 09:27, 8. Apr. 2020 (CEST)

Vielen Dank für die Rückmeldungen. Aber was ist zum Beispiel damit: Russisches_Imperium_Helenendorf_1910.jpg? Die Lizensierung ist als "gemeinfrei" freigegeben wie es auch in dem ©-Kasten steht, liegt jedoch auf einem "ru-Server". Und nun? --Wikaz2012 (Diskussion) 00:43, 12. Apr. 2020 (CEST)

Jemanden fragen, der sich damit auskennt. Eventuell kann dir Leyo da helfen, oder Nightflyer. Hier ist ja eher die Diskussionsseite zu einer Hilfeseite, die die Syntax zur generellen Einbindung beschreibt (wie Bilder, Grafiken und Karten in Artikel eingefügt und platziert werden) und nicht für solche Spezialanfragen gedacht ist.

Wie ich schon schrieb Zitat: „frage besser auf der Seite Wikipedia:Urheberrechtsfragen nach“. Ich kann dir dazu leider keinerlei Auskünfte geben, da ich schlicht nicht weiß, wie die russische Sprachversion arbeitet und ob dieses Bild auch nach unseren Urheberrechtsrichtlinien gemeinfrei wäre. Damit kenne ich mich nicht aus. --Liebe Grüße, Lómelinde Diskussion 06:51, 12. Apr. 2020 (CEST)

Link zu Bild mit Wikilink

Gibt es eine einfache Möglichkeit ein Bild nicht einzubinden, sondern nur zu verlinken, e.g. so: [[Datei:Beispiel.jpg|keinbild]]? Das wäre schöner als Datei:Beispiel.jpg. --Petermahlzahn (Diskussion) 22:17, 6. Jun. 2020 (CEST)

Meinst du Keinbild? Habe ich in Artikeln noch nie verwenden müssen. --Milseburg (Diskussion) 22:34, 6. Jun. 2020 (CEST)

(BK)Mit einem Doppelpunkt vor "Datei:", also [[:Datei:Beispiel.jpg|kein Bild]] ergibt kein Bild. --Digamma (Diskussion) 22:37, 6. Jun. 2020 (CEST)

Danke @Milseburg und @Digamma, ich brauche das eher für Diskussionen … Jetzt sehe ich auch den zugehörigen Abschnitt auf der Hilfeseite: Hilfe:Bilder#Erzeugen eines Links zur Dateibeschreibungsseite.--Petermahlzahn (Diskussion) 11:27, 7. Jun. 2020 (CEST)

Rahmenlose – Bildgrösse

Im Abschnitt Hilfe:Bilder#Rahmenlose_Einbindung_(ohne_Miniatur) steht, man solle hochkant=1.39 benutzen damit das bild die grösse von mini hat, allerdings wird es bei mir dann als zu gross angezeigt, ohne parameter hockannt passt die grösse:

[[Datei:DBP 1990 1465-R.JPG|mini|„mini“]]
[[Datei:DBP 1990 1465-R.JPG|rahmenlos|rechts]]
[[Datei:DBP 1990 1465-R.JPG|rahmenlos|rechts|hochkant=1.39]]

sollte das auf der vorderseite geändert werden, oder verstehe ich das falsch? gruss, --Wetterwolke (Diskussion) 21:58, 27. Apr. 2021 (CEST)

Mit [[Datei:DBP 1990 1465-R.JPG|rahmenlos|rechts|hochkant=1.039]] passt es. habe es umseitig angepasst. --Wetterwolke (Diskussion) 13:35, 24. Mai 2021 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Wetterwolke (Diskussion) 13:35, 24. Mai 2021 (CEST)

Zwei Bilder mit gemeinsamer Bildunterschrift

Gemeinsame Bildlegende für zwei Bilder

Gibt es eine Möglichkeit, zwei Bilder nebeneinander darzustellen und dabei anstelle zwei separater Bildunterschriften eine gemeinsame Bildunterschrift anzugeben?--Stegosaurus (Diskussion) 18:56, 20. Aug. 2020 (CEST)

Vorlage:Doppeltes Bild --Liebe Grüße, Lómelinde Diskussion 19:02, 20. Aug. 2020 (CEST)

Bitte um Feedback

wie vor einiger Zeit im Kurierbeitrag in der Wikipedia bereits angekündigt wurde, beteiligt sich Wikimedia Deutschland mit dem Projekt „Wiki Loves Monuments goes ECHY 2018“ (ECHY steht für „European Cultural Heritage Year“) am Europäischen Jahr des Kulturerbes. Durch dieses Projekt sollen der Fotowettbewerb weiterentwickelt, die Bekanntheit der Arbeit der Freiwilligen erhöht und auf einem Austausch- und Planungsportal zum Europäischen Kulturerbe auf Wikimedia Commons zur Teilnahme und Mitgestaltung eingeladen werden.

Wie dort dargestellt, sieht es ein Projektbaustein vor, dass der Fotowettbewerb Wiki Loves Monuments weiterentwickelt wird. Dazu wird die aktuelle (technische) Entwicklung, Objekte in ungewohnten Darstellungen zu präsentieren, aufgegriffen und u. a. ein Fokus auf 360°-Panoramen gelegt. So wird es im Rahmen von „Wiki Loves Monuments goes ECHY 2018“ folglich auch Sonderpreise für 360°-Panoramen von Kulturerbestätten geben.

Damit solche Panoramen entstehen können, benötigen freiwillige Fotograf_innen den Zugang zu Kulturerbestätten. Um diesen Zugang zu erleichtern, möchte Wikimedia Deutschland ein Unterstützungsdokument bereitstellen, um freiwilligen Fotograf_innen eine Argumentationshilfe an die Hand zu geben und den Besitzenden und (Zugangs-)Verwaltenden von Kulturerbestätten Informationsmaterial zur Verfügung zu stellen und so möglichst Bedenken oder Vorurteile gegenüber Wikipedia, Wikimedia Commons und freien Lizenzen auszuräumen.

Dieses Dokument soll in Form eines Flyers in gedruckter und digitaler Form erscheinen. Für die Textinhalte gibt es einen ersten Entwurf (Google Doc – zum kommentieren ist kein Account/keine Anmeldung vorausgesetzt). Ich würde mich freuen, wenn ihr zu diesem Dokument bis zum 11.06. Kommentare, Verbesserungsvorschläge und Korrekturen hinterlassen könntet. Das Layout und alles weitere zur äußerlichen Erscheinung erfolgt zu einem späteren Zeitpunkt.

Bei Rückfragen stehe ich euch gern zur Verfügung und danke euch schon mal für euer Feedback.

--Jonas Sydow (WMDE) (Diskussion) 11:04, 4. Jun. 2018 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Wetterwolke (Diskussion) 14:11, 6. Aug. 2021 (CEST)

Leerzeichen im Dateiname

Auf Commons gibt es sowohl Bilder, die Leerzeichen ( Blanks ) im Dateinamen haben, als auch welche, bei denen der Hochladende die Leerzeichen durch Unterstriche (Underscores) ersetzt hat. Anscheinend funktioniert es in beiden Fällen, sowohl den eigentlichen, 'echten' Dateinamen in der [[Datei:Bildname.sfx]]-Angabe zu verwenden, als auch die jeweils andere Variante. Der "Artikel zum Bild" bei Commons scheint immer Underscores durch Leerzeichen zu ersetzen.

Ich konnte weder bei Commons noch hier finden, was nun bevorzugt wird - immer Leerzeichen verwenden? Oder besser mit dem Originalnamen einbinden, wenn dieser Unterstriche enthält?

Ich nehme mal an, dass es zumindest keine Lizenzverletzung darstellt, einen WP-internen "alternativen Dateinamen" zu verwenden, zumindest solange nur Blanks und '_' hin- und hergewandelt werden.

--arilou (Diskussion) 13:54, 29. Sep. 2020 (CEST)

Das ist rechtlich völlig einerlei.

Es sind unterschiedliche Kodierungen desselben Namens.

Siehe: Hilfe:Seitenname #canonical

Wenn man es Menschen präsentiert, etwa bei Anzeige des Seitennamens oder auch in unserem Quelltext, macht man Leerzeichen und zeigt Umlaute usw. dekodiert.
In einer URL darf es keine Leerzeichen geben, es ist _ zu verwenden und statt ö sollte es %C3%B6 sein. Wobei %20 statt Leerzeichen auch funktioniert und die Internet-Mechanismen auch mit ö klarkommen müssten.
Für den Eintrag in der Wiki-Datenbank muss es _ und ö sein.

VG --PerfektesChaos 14:36, 29. Sep. 2020 (CEST)

Nochmal zu (meinem) besseren Verständnis:

Ein "eingebundenes Bild" (via wikicommons) ist nicht das Bild selbst, sondern die zugehörige Seite von wikicommons,

und daher sollte man, wie bei WP-internen Links, stets Blanks verwenden? (Also insbesondere im Quelltext eines WP-Artikels beim [[Datei:...]]-Einbinden.)

--arilou (Diskussion) 17:01, 29. Sep. 2020 (CEST)

[[Datei:Église Saint-Nectaire, Saint-Nectaire-3037.jpg]] und [[Datei:Église_Saint-Nectaire,_Saint-Nectaire-3037.jpg]] sind absolut gleichwertig. Für die bessere Lesbarkeit im Quelltext wird idR die Variante mit Leerzeichen verwendet. Änderungen in die eine oder andere Richtung sind nicht notwendig. — Raymond ^Disk. 18:18, 29. Sep. 2020 (CEST)

Mindestens rechtfertigt sowas weder einen Edit nur um es umzuschreiben, noch ein Anmeckern von jemandem der das geschrieben hatte.

WSTM und wohl auch einige andere Werkzeuge konvertieren das in die Quelltext-Standardform, falls sie zufällig dran vorbeikämen.

Es werden öfters URL kopiert, und bei denen steht dann Bremische_B%C3%BCrgerschaft und dann ist das halt erstmal so.

VG --PerfektesChaos 18:38, 29. Sep. 2020 (CEST)

Ich fände es sinnvoll, wenn dazu 1-2 Sätze in hiesigem Hilfe-Artikel stünden. --arilou (Diskussion) 13:39, 30. Sep. 2020 (CEST)

Nein.

Hier umseitig geht es um etwas völlig anderes.

Was eine Seite ist, wie in den Wikis eine Seite bezeichnet wird, dass es verschiedene Möglichkeiten gibt, den Namen derselben Seite zu kodieren – das ist hier absolut fehl am Platz und nicht das Thema.

Thema umseitig ist die Technik der Einbindung einer Mediendatei mit zahlreichen Optionen dazu.

Umseitig ist ohnehin schon sehr überfrachtet und unübersichtlich; niemand würde auch noch diese Idee finden.

VG --PerfektesChaos 13:51, 30. Sep. 2020 (CEST)

Thumbnail-Überschriften von WP-Artikeln unpräzise

Wo finde ich ein Portal, bei dem ein Feature vorzuschlagen wäre, dass WP-Artikel, die man als Link zu einem bestimmten Abschnitt z.B. per iMessage verschickt, auch mit diesem Abschnittstext als Thumbnail angezeigt werden und nicht mit dem Lemma an sich? Es wäre so einfacher, sich über konkrete WP-Inhalte zu verständigen.--ChickSR (Diskussion) 12:14, 17. Nov. 2020 (CET)

@ChickSR:

Das Portal wäre Wikipedia:Verbesserungsvorschläge.
Wir sind allerdings nicht für iMessage und Darstellung von Thumbnails zuständig.
- Wer auch immer da sowas darstellen möchte, müsste sich selbst was programmieren.
- Wir bieten dazu eine API an: mw:Specs/Summary/1.2.0
- Da stehen alle Einzelinformationen drin. Aus denen muss sich der Verwender eine Darstelllung für den jeweiligen Empfänger zusammenbasteln.
- Beispiel für Bild: https://de.wikipedia.org/api/rest_v1/page/summary/Bild
  - https://de.wikipedia.org/api/rest_v1/page/summary/Bild_(Fotografie)

Abschnitte, wie explizit eingefordert wird, gibt es dort allerdings nicht; das liegt daran, dass ein Abschnitt keinen Einleitungsabschnitt hat. Einleitungsabschnitte haben per Definition nur ganze Artikel.

Kann der ausführende Programmierer aber selbst leicht rausfinden und damit machen was er will.
https://de.wikipedia.org/api/rest_v1/page/html/Hilfe_Diskussion:Bilder

Der rote Kasten ist nicht so ganz getroffen worden, die Anfrage hat auch absolut nichts mit Bildern im umseitigen Sinn zu tun, und wäre bei WP:FZW besser aufgehoben gewesen.

VG --PerfektesChaos 17:11, 17. Nov. 2020 (CET)

Vielen Dank für deine ausführliche Antwort. Da ich kein Programmierer bin, kann ich damit leider wenig anfangen und werde die Frage noch einmal bei den Verbesserungsvorschlägen stellen.--ChickSR (Diskussion) 17:17, 17. Nov. 2020 (CET)

Rahmenlos mit Unterschrift?

Gibt es eine Möglichkeit, ein Bild rahmenlos mit Unterschrift anzuzeigen? --BurghardRichter (Diskussion) 22:22, 16. Jan. 2021 (CET)

Suchst ein Beispiel: Helmut Schmidt Gruss --Nightflyer (Diskussion) 22:31, 16. Jan. 2021 (CET)

Oder meinst du eine "normale Bildunterschrift"? Mit "rahmenlos" geht es nicht. Mit dem Umweg als Galerie würde es gehen.

Rotkehlchen

<gallery mode="nolines" class="float-right">
Rotkehlchen gr.jpg|[[Rotkehlchen]]
</gallery>

Gruß, --Alraunenstern۞ 22:36, 16. Jan. 2021 (CET)

Die Galeriefunktion ist aber eigentlich nicht dafür gedacht sie nur dafür zu verwenden, um persönlich bevorzugte Layouts zu gestalten. Bitte dieses Beispiel (individuelle Einzelbildgestaltung) nicht in Artikeln verwenden. Galerien sollte aus mehreren Bildern bestehen, der Sinn der gallery-tags ist es mehrere Bilder darzustellen. Siehe auch Help:Images/de#Anzeigen einer Bildergalerie --Liebe Grüße, Lómelinde Diskussion 06:50, 17. Jan. 2021 (CET)

Vielen Dank für die Hinweise! Mein Problem betraf das Portraitphoto im Artikel Adolf Hitler (Permanentlink des früheren Zustands) mit darunter als rahmenloses Bild dargestellter Signatur. Die Diskussion:Adolf Hitler #Signatur hatte ergeben, dass die Abbildung der Signatur einer erläuternden Bildunterschrift bedurfte. Da sie rahmenlos war, brachte mein erster Versuch nicht das gewünschte Ergebnis. Es müsste in diesem Fall möglich sein, auch ein rahmenloses Bild mit einer Unterschrift zu versehen. Darum meine obige Anfrage. In der englischen WP gibt es dafür die Vorlage en:Template:Plain image with caption, die wir in der deutschen WP leider nicht haben.

Mittlerweile habe ich eine Lösung gefunden, auf die mich Nightflyers Hinweis auf den Artikel Helmut Schmidt gebracht hat. Dort ist, anders als in der früheren Version des Artikels Adolf Hitler, die rahmenlose Abbildung der Signatur nicht als separates Bild unterhalb des Portraitphotos angeordnet, sondern in die Bildunterschrift des Portraitphotos integriert, also eine Abbildung innerhalb der Bildunterschrift einer anderen Abbildung. Das Muster habe ich übernommen und dann nach der eingefügten Signaturabbildung noch den Text, der darunter stehen sollte, hinzugefügt. Und so funktioniert es! --BurghardRichter (Diskussion) 21:31, 18. Jan. 2021 (CET)

„alt=“ funktioniert nicht mehr!

Hallo, ich wunder mich gerade, warum die Alternativtexte nicht mehr angezeigt werden!? Bei Miniatur-Bildern funktionieren sie generell nicht mehr und bei direkt eingefügten Bildern nur noch dann, wenn man das alt= davor weglässt. Evtl dachte ich, es hat was mit class=noviewer zu tun oder mit verlinkten Bildern. (Letztere zwar indirekt ja, da dann das Linklemma angezeigt wird und kein tooltip, siehe Tabelle unten.) Aber nein, alt= funtioniert nicht mehr und noch schlimmer, es ist kontraproduktiv!! Das heißt, Alternativtexte funktionieren schon noch, doch sobald alt= davor steht, wird er nicht mehr angezeigt. Ist das nur mir aufgefallen? Läuft dazu schon irgendwo eine Diskussion? Das müsste dann evtl. in der Bilderhilfe korrigiert werden, und v.a. auch unter Wikipedia:Barrierefreiheit.

~~Tooltip/Alternativtext bei Mouseover~~^{Verwirrtheit 1.Grades}
Bild	Anzeige angemeldet	Anzeige unangemeldet	mit `class=noviewer`	mit `link=Vex…`	„Alternativtext“ mit „`alt=`“ davor	mit `mini`
	AltText	AltText	-	-	-	-
	--	--	-	-	++	-
	AltText	PagePreview	-	++	-	-
	LinkLemma	PagePreview	-	++	++	-
	AltText	AltText	++	-	-	-
	--	--	++	-	++	-
	AltText	PagePreview	++	++	-	-
	LinkLemma	PagePreview	++	++	++	-
Alt1	--	--	-	-	-	++
Alt1	--	--	-	-	++	++

Grüße --W like wiki ^{good to know} 20:58, 8. Jan. 2022 (CET)

Eigentlich sollte es nur eine Fehleranalyse geben, siehe hier Wikipedia:Projektneuheiten#6. Januar 2022. Dabei sollte aber nicht der Alternativtext abgeschaltet werden, sondern im Gegenteil, es sollte erreicht werden, dass Texte, die bisher nur als Tooltip ausgegeben wurden auch als Alternativtexte zugänglich gemacht werden.

Du hast hier jetzt beispielsweise Linterfehler erzeugt indem du eine doppelte Bildlegende verwendest Fehlerhafte Dateioptionen. Diese Fehlerkategorie gibt es aber schon länger. Neu hinzugekommen ist diese Inline-Medien mit Bildunterschriften die Softwareumstellung scheint nicht das zu erreichen was geplant war. Ich habe nämlich schon eine Flut an Fehlern in der neuen Kategorie erwartet, aber sie ist leer, siehe auch T297443 phabricator oder Help:Lint errors/inline-media-caption. Ich rufe mal Raymond vielleicht kann er etwas tun oder dazu sagen. Wenn ich es richtig verstanden hatte, ging es darum so etwas Bild ohne mini nur mit Tooltiptext [[Bild:FIAV 001001.svg|20px|Vexillologisches Symbol]] aufzuspüren und mit einem (zusätzlichen?) Alternativtext

[[Bild:FIAV 001001.svg|20px|Vexillologisches Symbol|alt=Vexillologisches Symbol zweireihiges Gittersymbol mit je einem Punkt in den rechts stehenden Kästchen]]

zu hinterlegen.

Was oben in deiner Tabelle angezeigt wird, ist aber nicht der Alternativtext sondern die normale Bildlegende. Der Alternativtext wurde, zumindest mir, noch niemals angezeigt, ich konnte ihn immer nur im Quelltext lesen. Hilfe:Bilder#Alternativtext und Wikipedia:Barrierefreiheit#Alternativtext für Bilder. Ich kann keinen Unterschied in der Anzeige feststellen, es funktioniert wie bisher. Ich habe allerdings auch keine Lesehilfen Screenreader-Optimierung eingeschaltet. --Liebe Grüße, Lómelinde Diskussion 07:10, 9. Jan. 2022 (CET)

@W like wiki @Lómelinde alt-Texte werden in einem Browser beim Mouse-over nie angezeigt. Nur der title-Text, der aus der Bildbeschreibung erzeugt wird. Ich habe im Betawiki einen etwas vereinfachten Test angelegt: https://de.wikipedia.beta.wmflabs.org/wiki/Test_alt_attribut . Für mich sieht das Ergebnis wie erwartet aus. Ihr könnt beide gerne weitere Beispiele dort ergänzen und ggfs. erklären, welche Variante falsch sein soll. --Raymond ^Disk. 10:29, 9. Jan. 2022 (CET)

Wie gesagt ich kann da kein verändertes Verhalten feststellen, mir ging es aber jetzt auch um die neue Linterfehlerkategorie, die auch im Beta-Wiki nicht zu funktionieren scheint. Ich wäre eigentlich ganz froh wenn das so bliebe, fürchte aber sie haben da etwas nicht scharf gestellt bei ihrer Analyse. --Liebe Grüße, Lómelinde Diskussion 10:45, 9. Jan. 2022 (CET)

Ach du jemine, was ist mir da passiert! Liebe @Lómelinde:, Lieber @Raymond: da hab ich im Eifer des Gefechts irgendwie „Alternativtext“ und „Tooltip“ verwechselt

Entschuldigt bitte! Für Extra-Verwirrung hat dann noch gesorgt, dass scheinbar zeitlich ein paar Überarbeitungen auf dem Gebiet stattgefunden haben. Naja, wie auch immer. Habe mich mal der Beta-Seite gewidmet und noch testweise ein thumb-Beispiel ohne alt-text ergänzt und den Android Screenreader drüberlaufen lassen – funktioniert alles ganz einwandfrei!

Hab also gelernt: wenn alt=alt-text angegeben, dann wird auch alt-text vorgelesen. Unabhängig davon wird bei Bildern, die direkt eingebunden sind, auch immer noch die Bildbeschreibung vorgelesen, also ganau in den Fällen, wenn bei Mouseover auch ein Tooltip angezeigt wird. Und so, wie bei den thumb-Beispielen kein Tooltip erscheint, so wird hier auch keine Bildbeschreibung vorgelesen, solange sich das Fokusfenster des Screenreaders noch auf dem Bild befindet. In den thumb-Fällen, in denen dann kein alt-text angegeben ist (also leider in den meisten Fällen) muß sich der Hörer hier den Dateiname anhören. Wechselt das Fokusfenster dann weiter auf die Bildbeschreibung, so wird die dann vorgelesen. Hmm, also alles beim alten scheinbar, Fehlalarm! Nun denn, beste Grüße --W like wiki ^{good to know} 07:58, 10. Jan. 2022 (CET)

Kein Problem, irren ist menschlich. --Liebe Grüße, Lómelinde Diskussion 08:05, 10. Jan. 2022 (CET)

Ach, herzlichen Dank!! --W like wiki ^{good to know} 08:20, 10. Jan. 2022 (CET)

Dieser Abschnitt kann archiviert werden. --W like wiki ^{good to know} 03:05, 11. Jan. 2022 (CET)

Kollagen

Nach meiner Anfrage in der Vorlagenwerkstatt wurde {{Collage}} in Wikidata verlinkt und User:Habitator terrae hat die Vorlage in Absprache mit mir erweitert.
Habitator terrae hat in der Vorlage bereits in meinen Augen sinnvolle Begrenzungen umgesetzt: max 4 Zeilen, max 2 Spalten sowie die unterschiedlichen Größenverhältnisse innerhalb einer Zeile abwechselnd festgelegt links bzw. rechts für die 1. und 3. Zeile bzw. für die 2. und 4. Zeile.
Meine Frage ist nun, soll das Thema Kollage Thema auf dieser Hilfeseite sein? Dann könnte man die Limits der Vorlage also die Empfehlungen für Kollagen in der Wikipedia nennen.
Zu klären wäre dann auch, ob Kollagen in Infoboxen platziert werden sollten. Diese Frage stelle ich aber unabhängig von der Erwähnung des Themas auf der Hilfeseite, da Kollagen bereits in Infoboxen platziert sind (z.b. Bangkok, Peking, Buenos Aires) --Mrmw (Diskussion) 08:04, 21. Feb. 2021 (CET)

Nein.

Die Methodik ist nicht empfehlenswert, und dass die Vorlage in ganzen drei Artikeln verwendet wird macht sie noch lange nicht vorbildlich.

Die Bildauflösungen (Pixelzahl) sind fest vorgegeben, während sie bei Miniaturbildern und Galerien von den Benutzereinstellungen abhängig sind und in der Regel dort deutlich kleiner ausfallen.
- Damit wird dort die übertragene Datenmenge erstmal für alle Leser kleiner, schneller und bei langsamen oder teuren Internetverbindungen auch sparsamer.
- Hier wird zwangsweise eine Bildgröße programmiert und gnadenlos in dieser Auflösung übertragen, egal ob man das wissen will oder nicht.
Die Bildlegenden sind nicht sichtbar.
- Sie müssen, statt mit einem Blick überflogen zu werden, erst durch interaktives Erfragen ermittelt werden.
- Auf Mobilgeräten gibt es keine Mauszeiger. Damit lässt sich nur das Bild anklicken und die Dateibeschreibungsseite aufsuchen. @XanonymusX: oder können die das inzwischen? Antatschen aber nicht anklicken?
Das Dingens animiert dazu, Ansichtspostkarten zusammenzukleben, beeindruckende bunte Facebook-Profile zu Reklamezwecken zu basteln, statt enzyklopädische Informationen seriös zu illustrieren.

Eine Galerie ist diesem Ding in jeder Hinsicht überlegen.

Es hat schon seinen Grund, warum wir das bis 2020 nicht hatten und wunderbar ohne auskommen.
Nicht jede technikbesoffene Fummelei, was so alles mit CSS oder sonstwie programmierbar wäre, ist auch für unser Projekt geeignet.
Und schon gar nicht ist jede CSS-Spielerei, die sich 2004 bis heute irgendwer in der enWP mal hingefummelt hat, nur deshalb eine Super-Idee weil es aus der enWP kommt.

Im Übrigen hat die umseitige Hilfeseite die MediaWiki-Software und deren Eigenschaften zu beschreiben, wäre damit schon gut gefüllt, und wird seit ewig damit überladen für irgendwelche Vorlagen Reklame zu machen – das gehört in die jeweilige Vorlagendokumentation und nicht hier noch breit illustriert und erklärt.

VG --PerfektesChaos 14:59, 21. Feb. 2021 (CET)

Ein paar Fragen und Erwiederungen:

Zur Bildauflösung:
- Der Regelfall hat keine eigen eingestellte Bildgröße mit eigenem Benutzeraccount. Der von der Vorlage verwendeter Standard von 220px ist der Standard für jeden unangemeledeten User.
- Hilfe:Bilder#Annotiertes Bild (Beschnitt und Text) ist von der Speicherarmut hierzu im Vergleich eine absolute Katastrophe und wird trotzdem hier empfohlen.
- Die Bildauflösung (ob mal 1 oder mal 1.5 oder mal 2) kann weiterhin frei im Browser bestimmt werden. Habitator terrae 21:43, 21. Feb. 2021 (CET)
Das mit der Bildlegende ist nun wieder korrigiert. War bei der Verbesserung hinzugekommen. Danke für den Hinweis.
Es verbessert Gallerien dadurch, dass einen kleineren Raum auch am Rand des Artikels einnehmen kann (können Gallerien nicht so gut).
Es handelt sich nicht um die Erfüllung eines Wunsches aus der Grafikwerkstatt, der nun auch in der Vorlagenwerkstatt aufkam, die die schon lang gepflegte Praxis von Collagen leichter umsetzen lassen möchte, ohne dass Bildbearbeitungskenntnisse bestehen müssen. Es vereinfacht nur diese bestehende Bilderkultur.

Habitator terrae

21:41, 21. Feb. 2021 (CET) PS: Und ja, Tabellen sind etwas altmodisch, dafür aber nicht so viel Fummelei.

Weil ich angepingt wurde: Nein, das Tap-Event können hierzupedia praktisch nur meine Schallplattenicons (

×14

×214-fach-Platin + Doppeldiamant ), das muss man schon extra erzeugen (und in iOS-Desktop ist es leider immer noch ein bisschen buggy). Aber das scheint ja jetzt nicht mehr das Problem zu sein. Ansonsten schauen die Vorlagenbeispiele auf der Doku auch mobil ganz gut aus, aber tiefer bin ich da nicht eingestiegen. Gruß–XanonymusX (Diskussion) 04:01, 23. Feb. 2021 (CET)

@PerfektesChaos, Habitator terrae: Ich würde mir wünschen in solchen Anfragen erst mal nicht vom schlechtesten auszugehen - ich will nicht für Vorlagen werben
Ich persönliche hänge nicht emotional an der Vorlage oder an ihrer Verwendung - für mich war das mehr ein Start ins Thema, als Vorschlag sozusagen.
Ich finde es auch wichtig, dass gerade für Neulinge die Hilfeseiten übersichtlich bleiben. Dennoch fehlt für mein Empfinden das Thema Kollagen. Mich interessiert, ob es hierzu Überlegungen oder, wenn man es so nennen will, Richtlinien gibt.
Ich erwarte keine klaren oder allgemeingültigen Regeln, nach denen man über alle Kollagen herziehen kann bzw. sollte. Ich wünsche mir lediglich eine Diskussion dazu. Und dazu habe ich eine Unterseite erstellt, in der eine Auswahl an Kollagen dargestellt ist, die in deutschen Artikeln enthalten sind:

Hilfe Diskussion:Bilder/Kollagen und Mehrfachbilder

Ich frage mich eben, ob und wie eine Kollage dem enzyklopädischen Anspruch genügt? Welche Kriterien sollte sie mindestens in ihrem Kontext erfüllen?
Viele Kollagen machen auf mich den Eindruck als wöllten sie eine 'Übersicht' für ein Thema geben? Wenn man die Idee aufnimmt, wo hört sie dann auf? In den Hilfeseiten steht, Bilder sollen den Text auflockern, aber doch mit informativem Mehrwert oder irre ich mich? Nach meinem Verständnis führt der Weg nach Commons wenn ich als Leser Interesse an einer größeren Anzahl an Bildern habe.
Mein persönlicher Anspruch, den ich aber hiermit auch zur Diskussion stelle - ist der, dass wo immer möglich Einzelbilder in Artikeln platziert werden. Dabei wird automatisch die Fragestellung unterstützt, ob die Vielzahl der Bilder aus der Kollage relevant und ausgewählt genug sind für das entsprechende Thema.
Ist das der richtige Ort für diese Diskussion? Ich schätze die Meinung eines jeden Einzelnen, nur interessiert mich auch wie andere darüber denken. --Mrmw (Diskussion) 14:49, 22. Feb. 2021 (CET)

Farbstich

Moin,

das hier gezeigte Bild, hochgeladen vom @LandesarchivSaarbrücken:, hatte in der Darstellung auf Wikipedia einen üblen Grünstich. Stellt man sie aber von der eigenen Festplatte aus mit der Fotoansicht oder dem Gimp dar, so ist dieser Farbstich nicht vorhanden. Ich bin dann mit dem Gimp in die Farbverwaltung gegangen, hab festgestellt, dass ein Farbprofil namens ChromeTX zugewiesen war, und hab dieses Profil durch das Standard-RGB-Profil ersetzt. Dann die geänderte Datei hochgeladen, und jetzt ist der Farbstich auch in der Wikipedia-Darstellung weg. – Das war aber ein rein experimenteller Ansatz. Im Grunde verstehe ich nichts von Farbprofilen. Kann eine Person, die sich wirklich damit auskennt, dem Landesarchiv einen Rat geben, wie am besten vorzugehen ist? – Danke und Gruß, --Mussklprozz (Diskussion) 09:03, 10. Mai 2021 (CEST)

Hi diese Hilfeseiten erklären mehr das funktionieren der wiki-software, Wikipedia:Fotowerkstatt kann vielleicht eher helfen. Gruss, --Wetterwolke (Diskussion) 13:20, 10. Mai 2021 (CEST)

Okay, ich stelle die Frage dort nochmals. Danke, --Mussklprozz (Diskussion) 13:48, 10. Mai 2021 (CEST)

Bild aus fa.wikipedia.org/wiki/

Hallo zusammen, ich wollte dieses Bild https://fa.wikipedia.org/wiki/%D9%BE%D8%B1%D9%88%D9%86%D8%AF%D9%87:Roomina_Ashrafi.jpg in einen de.-wikipedia-Artikel einbinden... Nur wie geht das!? Auf Wikimedia Commons ist es nicht zu finden.--Semleiter (Diskussion) 19:08, 11. Mai 2021 (CEST)

Nur was auf Commons ist, ist international freigegeben. -- →^KP_G← 19:25, 11. Mai 2021 (CEST)

Genauer: Die verwendete Lizenz des Bildes ist Fair use. Das ist in unserer Wikipedia-Version nicht erlaubt. Gruss --Nightflyer (Diskussion) 20:05, 11. Mai 2021 (CEST)

Danke & schade.--Semleiter (Diskussion) 21:10, 11. Mai 2021 (CEST)

"Unsichtbarer" Rahmen

Mit der Option "rand" kann man zwar einen Rand direkt um das Bild herum einfügen. Ich vermisse aber eine Funktion, um einen breiteren "unsichtbaren" Rahmen um das Bild herum anzulegen. "Unsichtbar" soll hier nur heißen, dass er dieselbe Farbe wie der Hintergrund hat. Viele Bilddateien mit zum Beispiel Logos sind nur exakt so groß wie das Logo. Wenn man so ein Bild dann in den Artikel einbindet, wird der Rand direkt drumherum gezeichnet, was sehr unschön aussieht. Das Logo braucht etwas "Luft" drumherum. Wie kann man das erreichen? -- H005 (Diskussion) 10:31, 3. Jun. 2021 (CEST)

Logo in Galerieform

Logo mit Abstand zu einem Rand über div-Tags, oder über die Galeriefunktion, beides nicht so, dass ich es gern empfehlen würde. Ansonsten ist eine solche Funktion nicht vorgesehen. Es ginge noch in der Bilderwerkstatt zu fragen, ob jemand ein Exemplar mit etwas mehr Randabstand erzeugen möchte. --Liebe Grüße, Lómelinde Diskussion 12:49, 3. Jun. 2021 (CEST)

Alternativtext in Infoboxen

Wie funktioniert das Einfügen von Alternativtexten bei Infoboxen? Ich wollte gerade das Logo von Pornhub beschreiben und weiß nicht wie, weil es da keine doppelt eckigen Klammern gibt. Danke vorab! --Fan (Diskussion) 17:01, 15. Jan. 2022 (CET)

In der jeweiligen Vorlage, dort wo das Bild generiert wird. Du musst dort ein |alt= einfügen. Wenn dort tatsächlich ein Alternativtext hin soll, muss ein zusätzlicher Parameter ({{{Alternativtext|}}}) eingeführt werden, der den Text aufnehmen kann → |alt={{{Alternativtext|}}} oder so ähnlich, das muss dann auch entsprechend in die Dokumentation übernommen werden. --Liebe Grüße, Lómelinde Diskussion 17:09, 15. Jan. 2022 (CET)

Es könnte evtl auch einfacher gehen. Da die Vorlage:Infobox Website das Logo wie folgt einbindet: [[Datei: {{{Logo}}} |center|250x250px|Website-Logo]] könnte als Eingabe im Artikel Pornhub folgendes reichen:

| Logo = Pornhub-logo.svg|alt=Schwarzes Rechteck mit weißer Schrift...

Damit |alt= nicht evtl als Parameter für die Infobox vertanden wird, sondern als Teil vom Logo, müsste es evtl so heißen:

| Logo = Pornhub-logo.svg{{!}}alt=Schwarzes Quadrat mit weißer Schrift...

Das sollte dann [[Datei:Pornhub-logo.svg|alt=Schwarzes Rechteck mit weißer Schrift... |center|250x250px|Website-Logo]] ergeben. Oder was meinst du @Lómelinde: Grüße --W like wiki ^{good to know} 03:00, 16. Jan. 2022 (CET)

Die letztgenannte Empfehlung ist von der Sorte „verabscheuungswürdiger übelster Hack“ und sollte auf keinen Fall befolgt werden.

Der Parameter Logo ist vom Typ Datei und es wird eingefordert, dass es ein gültiger existierender Dateibezeichner ist, und auf .svg oder .jpg usw. endet.

Wenn wir eines Tages anfangen, die Gültigkeit dieser Parameter zu prüfen, dann muss dieser ganze Pfusch wieder zurückgebaut und gelöscht werden.

Es ist so, wie Lómelinde schrieb: Wenn eine solche Information unterstützt werden soll, dann muss ein entsprechender Parameter eingeführt werden.

Wobei es für Blinde durchaus sinnvoll wäre, wenn ihnen die Gestaltung eines Logos beschrieben wird, das zum Gegenstand des Artikels gehört.

VG --PerfektesChaos 06:57, 16. Jan. 2022 (CET)

BK

So etwas habe ich aber absichtlich nicht als Alternative angegeben, weil das {{!}} eigentlich Syntax der Vorlagenprogrammierung ist, und nicht in Artikel gehört. Es geht vieles, aber, ob es auch immer sinnvoll und laienverständlich ist, ist eine andere Sache. Mit einem eigenen Parameter kann es hingegen für alle verständlich angeboten und mit der Vorlage ausgeliefert werden. --Liebe Grüße, Lómelinde Diskussion 06:46, 16. Jan. 2022 (CET)

Danke für eure Hinweise! Leider ist es mir im Moment nicht möglich die Vorlage entsprechend umzuprogrammieren: Wie kann ich denn den Quelltext der Vorlage bearbeiten? Ich kenne nur Vorlage:Infobox und Hilfe:Vorlagen. Alternativ würde ich mich auch freuen, wenn das wer einfach übernimmt. Danke für jede Hilfe dazu :) --Fan (Diskussion) 12:22, 16. Jan. 2022 (CET)

Wie jede andere Seite auch, Seite Vorlage:Infobox Website aufrufen auf bearbeiten klicken. Ich habe da jetzt einen Parameter Alternativtext hinzugefügt, ob das funktioniert musst du testen, denn ich verwende keinen Screenreader. Das wird, um es klar zu sagen, nicht als Tooltip angezeigt, sondern Blinden Benutzern vorgelesen. Wenn es da ist was du wolltest, dann kann es in die Dokumentation übernommen werden, wenn nicht würde ich den Parameter wieder entfernen. --Liebe Grüße, Lómelinde Diskussion 13:49, 16. Jan. 2022 (CET)

Vielen Dank! Ja, richtig, ich mache das nur der Barrierefreiheit wegen. Leider habe ich auch keinen Screenreader, aber ich frage mal wen. Und wenn das funktioniert kann ich das ja analog zu deinem Edit für die anderen Infoboxen analog machen, natürlich inkl. Dokus. Ich melde mich hier nochmal wenn ich eine Rückmeldung haben. Vielen lieben Dank für die Hilfe! Beste Grüße --Fan (Diskussion) 17:45, 16. Jan. 2022 (CET)

@Fan-vom-Wiki: Hast du ein Android-Smartphone? Da ist standardmäßig ein Screenreader dabei, Anleitung hier. Beste Grüße --W like wiki ^{good to know} 21:03, 16. Jan. 2022 (CET)

Ja liebe Kollegen, ok, mein Hack ist vielleicht eher rough&dirty, doch würde er auch gleich bei allen anderen Infoboxen funktionieren und das vor allem sofort. Aber ich bin natürlich auch ein Freund von sauberen und perfekten Lösungen, doch sind wir da dann erst gaanz am Anfang. Jetzt haben wir für die Infobox Webseite eine Lösung gefunden und einen neuen Parameter eingeführt. Als nächstes müsste sich dann jemand mal ein halbes Jahr freinehmen und bei den anderen 4.200 Infoboxen weitermachen. Bei einer Stichprobe von zehn, habe ich bei einer einzigen (Vorlage:Infobox Moschee) einen Parameter für einen Alternativtext gefunden (bild_alt). Das Problem, was @Fan-vom-Wiki: angespricht, ist ja eher von grundsätzlicher Natur und vor allem eines, was sich bei der Anlage neuer Infoboxen weiter ausbreitet. Um schon mal letzterem entgegenzuwirken, sollten wir vielleicht zu aller erst mit einer Erweiterung der Basisvorlage:Infobox um einen Parameter für Alternativtext beginnen. Der Parametername sollte aussagekräftig gewählt werden, "Alternativtext" versteht ja nicht jeder und ich denke, das ist auch einer der Gründe, warum er so wenig verbreitet ist. (Einschub: Warum benutzt man eigentlich immer noch dieses Wort "Alternativtext" aus alten Zeiten? Das beschreibt doch nur noch schlecht die heutige Verwendung! Würde man dem heute einen Namen geben, so würde man ihn doch viel mehr "Gesprochener Text" nennen und statt alt= evtl gesprochen= oder spoken= für "spoken text".) Zurück zur Infobox: bild zeigt oder Bildbeschreibung wären auch treffendere Parameternamen als dieses "Alternativtext", doch werden die teils schon verwendet und meinen dann meist die Bildunterschrift. Vielleicht wäre Bildbeschreibung_Screenreader oder Bildbeschreibung_gesprochen eine bessere Idee? Die kapiert dann jeder, sind aber auch recht lang. Kürzer und in Anlehnung an Vorlage:Infobox wäre noch Bildtext_gesprochen. Oder man hofft halt, das irgendwann alle Leute wissen, was mit "Alternativtext" gemeint ist und nennt den Parameter eben Alternativtext, Bild_Alttext oder bild_alt. Beste Grüße --W like wiki ^{good to know} 20:42, 16. Jan. 2022 (CET)

„gleich bei allen anderen Infoboxen“
- Es gibt nur eine Handvoll Infoboxen, bei denen eine solche Bildbeschreibung des Emblems sinnvoll ist; „Website“ hat jetzt, dann noch „Unternehmen“, „Verein“, „Partei“.
- Es ist in aller Regel weder sinnvoll noch von Autoren zu leisten, jedes Bildchen mit einer Beschreibung zu versehen, weil nur Dekoration oder wenn inhaltlich aussagekräftig dann an anderer Stelle zu lösen.
- Ortschaften usw. haben ein bis zwei Bildchen: Ein Luftbild oder sonst ein Foto, und das Wappen; vielleicht noch eine Flagge.
- Ein solches Foto ist völlig nichtssagend und nett für Sehende. Für Blinde ohne Aussagekraft: Links und rechts bewaldete Hügel, dazwischen viele Häuser. In der Mitte ein Kirchturm, der mit dunklem Material gedeckt ist. – Und nun? Hunderte andere Ortschaften sehen genauso aus; eine Brücke führt über einen FLuss und dahinter stehen Häuser. Was ist „das Bild“ von Wien, Hamburg, Genf, das jetzt irgendwas in einem einzigen Foto über die gesamte Ortschaft aussagt?
- Zu Wappen gehört eine Blasonierung; und die ist auch für Sehende relevant und darf nicht ausschließlich für Screenreader zugänglich sein. 10.000 Ortschaften.
„Basisvorlage:Infobox“
- Da hast du wohl was nicht begriffen.
- Es ist mitnichten so, dass Vorlage:Infobox im Sinne von Vererbung die Mutter aller Infoboxen wäre, die für alle anderen irgendwas durchreicht oder anbietet.
- Vielmehr ist es die Rückfallposition, wenn etwas wie eine Infobox aussehen soll, für das es keine Infobox gibt, und hat ganze 3200 Einbindungen – gegen weit über einer halben Million der themenspezifischen.
- Deine Aktion war einigermaßen wirkungslos.
„Warum benutzt man eigentlich immer noch dieses Wort "Alternativtext" aus alten Zeiten?“
- Das hat den simplen Grund, dass es der international übliche und seit zwei Jahrzehnten eingeführte Begriff dafür ist.
- Was auch immer du für dir jetzt für ein anderes Wort ausdenken magst, es wäre eins, das niemand außer dir kapieren würde.
- Alternativtext leitet auf unseren entsprechenden Artikel, und auch die Draußenwelt verwendet es.
- In der umseitigen Medieneinbindung ist alternativtext= ein Alias für alt=.
- Noch gebräuchlicher ist hingegen „Alt-Text“.
- Wir hätten gern Parameternamen, die handhabbar kurz und selbsterklärend sind. „Bildbeschreibung“ unterscheidet sich in der Bedeutung kaum von der Bildlegende, und genau dieses Wort verwenden bereits seit etlichen Jahren sehr viele Vorlagen als Parameter für die auch Sehenden zugängliche Bildlegende bzw. den Tooltip.
- Intelligent ist es hingegen, als Parameternamen genau den zu verwenden, der eine definierte Bedeutung hat, während deine Ideen alle missverständlich sind.

VG --PerfektesChaos 18:27, 17. Jan. 2022 (CET)

Hier gibt es eine gut dokumentierte Lösung. Somit hier erl.

Archivierung dieses Abschnittes wurde gewünscht von: --Fan (Diskussion) 01:05, 30. Jun. 2022 (CEST)

Drehung eines vorhandenen Bildes um 180° bzw. ±90° ?

Vereistes Rotorblatt einer Windkraftanlage in Norddeutschland. Betroffen ist die Blattvorderkante. Die Anlage wurde durch das Eiserkennungssystem gestoppt.

Dieses etwas kuriose Bild möchte ich zu Diskussionszwecken (auf dortiger Diskussionsseite zu Windkraftanlagen [[3]]) um 180° drehen. Dann ist für meine optische Wahrnehmung der weiss-rot-weisse Ausschnitt das Rotorblattes besser erkennbar. Gibt es für die nachträgliche Drehung eines bereits hochgeladenen Bildes eine Option für den Befehl zur Bildeinbindung - ohne die Datei auf dem lokalen Rechner zu drehen und nochmal hochladen zu müssen, also etwas in der Art »|rotate=180|«, o.ä. ? --NeptunT (Diskussion) 05:19, 3. Nov. 2021 (CET)

Theoretisch ja.

Jedoch nicht in Artikeln, nur im BNR, Diskussionen und sonstwie intern.

Nicht robust, und es ist nicht gewährleistet, dass dies auf jedem Endgerät pixelsauber dargestellt werden kann.

Oben stellst du ein Miniaturbild dar, was auch gut ist, weil es den Lesern Netzwerkressourcen spart, die sich gar nicht für die Details interessieren. rotate geht jedoch syntatisch nur mit nackten Bildern fester Größe, weil sonst auch die Legende hochkant oder auf dem Kopf stünde.

Es kommt auch gern zu Layout-Fehlern, weil das Bildformat Höhe×Breite zuvor abgefragt und dafür Platz im Layout reserviert wird, und der Text diesen freigehaltenen Platz schon mal umfließt, während das Bild noch geladen wird. Danach ist das Bild da, dann wird darauf das CSS angewendet, und mit etwas Glück wird dann Höhe×Breite gedreht, der Text, der zuvor vielleicht in das endgültige Rechteck reinschrieb, wird neu layoutet, und es springt nachträglich. Oder verreckt auf halber Strecke.

VG --PerfektesChaos 09:27, 3. Nov. 2021 (CET)

Dankend vielmals. So in etwa hatte ich mir das auch zur vereinzelten Verwendung auf Diskussionsseiten vorgestellt :-) . --NeptunT (Diskussion) 21:47, 3. Nov. 2021 (CET)

Hinweis auf unfreie Bilder

Es gibt doch die Möglichkeit auf ein unfreies Bild woanders hinzuweisen - das sollte hier irgendwo erwähnt werden. --Bahnmoeller (Diskussion) 00:09, 26. Jan. 2022 (CET)

Nö, das hier ist die softwaretechnische Beschreibung der Wikisyntax zur Medieneinbindung.

Du meinst inhaltliche Fragen wie Wikipedia:Bildrechte oder Wikipedia:Artikel illustrieren – beide sind bereits im Einleitungsabschnitt erwähnt, Wikipedia:Artikel illustrieren auch besonders hervorgehoben.

Umseitig ist bereits übermäßig lang und völlig unübersichtlich, und das wird nicht verbessert dadurch, dass immer mehr nicht auf diese Seite gehörender Kram auch noch irgendwo dazwischengeklatscht würde. Erstens findet das sowieso dort niemand, zweitens ist es gemäß der Zielvorgabe für diese Seite nicht zu erwarten und nicht danach zu suchen, und drittens wird dadurch alles andere noch schlechter zu durchschauen und beeinträchtigt.

Dein Begehren müsstest du auf einer Projektseite im Wikipedia-Namensraum einbringen; hier umseitig unzuständig.

VG --PerfektesChaos 00:21, 26. Jan. 2022 (CET)

Auf keiner der von dir genannten Seiten steht dazu etwas - aber geben tut es diese Möglichkeit. --Bahnmoeller (Diskussion) 00:34, 26. Jan. 2022 (CET)

„Dein Begehren müsstest du auf einer Projektseite im Wikipedia-Namensraum einbringen“ – das bedeutet, dass du dort, im Wikipedia-Namensraum, die von dir gewünschte Erwähnung vorschlagen müsstest.

Generell illustrieren wir unsere Seiten jedoch mit existierenden, also bereits hochgeladenen Bildern; das trifft insbesondere für umseitig zu. Eine Illustration mit nur verlinkbaren Verweisen ist etwas randständig.

VG --PerfektesChaos 01:13, 26. Jan. 2022 (CET)

Öffnen von Bildern in Wikipedia bzw. Commons / Anzeige der Kategorisierung

Ich bearbeite häufig Denkmallisten wie beispielsweise die Liste der Kulturdenkmale in Freiberg-Süd. Dort sind teils hunderte Bilder eingebunden, deren Kategorisierung nicht immer stimmt und deshalb überprüft werden muss. Wenn man die Bilder öffnet, landet man aber leider nicht direkt bei Commons und kann auch nirgendwo sehen, welche Kategorien diesem Bild zugeordnet sind. Hunderte Bilder durch einen weiteren Klick bei "Auf Wikimedia Commons ansehen" einzeln in Commons zu öffnen, treibt mich in den Wahnsinn - der Aufwand kann gerne am Beispiel nachvollzogen werden. Ich würde dringend um eine Verbesserung bitten. Mir fehlt die Expertise, um diese selbst umsetzen zu können, ich hätte aber zumindest theoretisch Lösungsvorschläge zu bieten:

Alle Bilder automatisch in Commons öffnen. Bei den Kategorien ist das auch so (siehe Klick auf "Weitere Bilder" unter dem ersten Foto im Beispiel). Warum man die Bilder mit absolut identischen, aber unvollständigen Informationen in Wikipedia spiegeln muss, erschließt sich mir nicht ansatzweise.
Falls es Gründe für die Spiegelung geben sollte, die für bestimmte Nutzer- oder Bearbeitergruppen relevant sind, wäre es eine Möglichkeit, eine Auswahlmöglichkeit zum wahlweisen Öffnen von Bildern in Wikipedia oder Commons in den Einstellungen einzurichten (so wie man auch den Medienbetrachter an- und abstellen kann).
Mein konkretes Problem wäre notfalls auch damit gelöst, wenn man wenigstens in der Wikipedia-Spiegelung die Kategorien der Bilder mit anzeigen würde. Das wäre aber die schlechteste Lösung, weil dann bei der Notwendigkeit einer Bearbeitung immer noch zu Commons gewechselt werden müsste.

Ich hoffe, jemand kann das Problem nachvollziehen und idealerweise lösen. Vielen Dank vorab, und sei es nur für die Aufmerksamkeit.--Lguenth1 (Diskussion) 13:44, 29. Dez. 2022 (CET)

Dein Problem lässt sich vermutlich leicht lösen: Setz unter Spezial:Einstellungen#mw-prefsection-gadgets einen Haken bei "Überspringen der lokalen Dateibeschreibungsseite, um sofort nach Commons zu kommen (mehr …)." --Magnus (Diskussion) 14:02, 29. Dez. 2022 (CET)

Danke erst mal für den Tipp, das war mir bei der Suche in den Einstellungen entgangen. Allerdings war der Haken bei mir schon gesetzt, und trotzdem lande ich auf der Dateibeschreibungsseite. Das ist auch nach Änderung und Broswerneustart so, sowohl in Opera als auch in Firefox. Funktioniert das bei Dir wie vorgesehen? Wo könnte sonst das Problem liegen?

Edit: Mit ein bisschen Suchen habe ich herausgefunden, dass dieses "Helferlein" nur funktioniert, wenn der Medienbetrachter (Media-Viewer) deaktiviert ist. Der ist zwar generell und für meine Zwecke eigentlich sehr hilfreich, aber zumindest habe ich dann mit einer vorübergehenden Deaktivierung eine Notlösung mit wenigen Klicks in den Einstellungen, während ich zuvor hunderte machen musste. Dankeschön.--Lguenth1 (Diskussion) 17:00, 29. Dez. 2022 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: --Lguenth1 (Diskussion) 17:00, 29. Dez. 2022 (CET)

Bilder als Links

Auf Liste der höchsten Windmühlen sind externe Links zu Bildern angegeben, die nicht im Medienarchiv Wikimedia-Commons oder im lokalen Dateibestand der Wikipedia hochgeladen sind. Ist das a) zulässig und wenn ja, b) erwünscht? --Gerald Fix (Diskussion) 06:32, 29. Apr. 2022 (CEST)

Was genau hat deine Frage jetzt mit dieser Hilfeseite Zitat: „Diese Seite erklärt, wie Du Bilder, Grafiken und Karten in Artikel einfügst und platzierst.“ zu tun? Sie dreht sich inhaltlich nicht, um das, was diese Hilfeseite angeht. Stelle deine Frage bitte auf der Seite WP:Fragen zur Wikipedia. Generell ist es aber nicht erwünscht im sogenannten Fließtext externe Links zu setzen. Siehe WP:Weblinks#Wo können Weblinks eingefügt werden?

Links zu externen Bildern sind zwar möglich, sie sollten dann aber als Beleg <ref>Link zum Bild</ref> formatiert werden.

Ob so etwas generell in der Form erwünscht ist, wird dir vermutlich niemand verbindlich beantworten können, da sind die Meinungen sicher unterschiedlich. --Liebe Grüße, Lómelinde Diskussion 09:49, 29. Apr. 2022 (CEST)

Meine Frage, etwas einfacher formuliert: Kann ich sämtliche Einschränkungen für Bilddateien dadurch umgehen, indem ich schlichtweg Links verwende? Kann ich damit auch Bilder in Wikipediaartikel einbinden, die nicht gemeinfrei, also urheberrechtlich relevant sind? - Mit der Einschränkung, dass diese Bilder dann nicht direkt sichtbar sind? --Gerald Fix (Diskussion) 10:08, 29. Apr. 2022 (CEST)

Da bist du hier falsch, das müsstest du wenn, dann hier Wikipedia:Urheberrechtsfragen erfragen. Ich weiß lediglich dass deine Frage nichts mit dieser Hilfeseite zu tun hat. Sorry, da kann ich dir nicht helfen. --Liebe Grüße, Lómelinde Diskussion 10:43, 29. Apr. 2022 (CEST)

Danke, das werde ich tun. --Gerald Fix (Diskussion) 14:55, 29. Apr. 2022 (CEST)

Hochkant immer hochkant?

Auf der Vorderseite steht: "hochkant muss nicht bei sämtlichen Bildern angegeben werden, die höher als breit sind". Ich habe daher in Steinwand (Rhön) kürzlich eine entsprechende Bearbeitung zurückgesetzt, weil durch das Setzen des Parmeters ein Bild nur kleiner wurde ohne dass sich sonst etwas am Leyout geändert hätte - jedenfalls auf meinen Geräten. Jetzt wies mich Benutzer:Joschi71 in der dazugehörigen Diskussion:Steinwand (Rhön) daraufhin, dass das Leyout bei anderen Geräten und Einstellungen durchaus nachteilig ist, wenn auf "hochkant" verzichtet wird. Daher ergibt sich für mich die Frage, von welchen Geräten und Einstellungen die Empfehlungen auf dieser Seite eigentlich ausgehen und ob es nicht sinnvoll wäre, tatsächlich zu empfehlen, dass alle Hochkant-Bilder den entsptechenden Parameter erhalten. Oder wie wird sichergestellt, dass es auf allen Geräten zur optimalen Anzeige kommt? --Milseburg (Diskussion) 21:09, 18. Mai 2022 (CEST)

Ich sage es mal so hochkant hat mehrere Funktionen, es ist besser skalierbar als eine feste Breitenangabe und kann daher auch zur Vergrößerung eines Bildes nützlich sein. Generell sollten Bilder nicht zu groß eingebunden werden insbesondere, wenn sich daneben weiteres Bilder Tabellen oder Infoboxen befinden und sich dazwischen Textpassagen befinden. Wenn ich die Darstellung hochkant mit normalem mini (220px) vergleiche sehe ich (am PC) einen deutlichen Unterschied, auch in der mobilen Ansicht ist das einfache hochkant deutlich kleiner, wobei eine Angabe hochkant=1 der Größe mini entspräche.

mini	hochkant	hochkant=1
Klettern in der Steinwand	Klettern in der Steinwand	Klettern in der Steinwand

Daneben gibt es in den Einstellungen Spezial:Einstellungen#mw-prefsection-rendering (Abschnitt Dateien) aber auch noch weitere Parameter, die das beeinflussen können. Bei mir wie gesagt ist dort 220px als Standard für mini ausgewählt. Die Skalierung wird sicherlich davon beeinflusst, welche Standardgröße man für sich dort eingestellt hat. Für mich ist es wichtig dass der Text gut lesbar bleibt, daher würde ich derartige Bilder eher hochkant einbinden. Die Hilfeseite beschreibt aber nur die Möglichkeiten der Einbindung, sie gibt nicht vor wer wann wo etwas wie zu machen hat. Da wäre vermutlich eher die Seite Wikipedia:Artikel illustrieren der bessere Ort, um das zu diskutieren. Leider ist aber das Empfinden wie ein Bild am besten in einen Artikel passt sehr unterschiedlich. Ich präferiere immer die Standardgröße (mini mit Standardausrichtung rechts) oder eben hochkant wenn die Bilder höher als breit sind und halte persönlich die Vergrößerung nur in seltenen Ausnahmen für sinnvoll. Bilder sollen den Artikel nur ergänzen nie dominieren, andere sehen das aber sicher anders. --Liebe Grüße, Lómelinde Diskussion 06:03, 19. Mai 2022 (CEST)

Danke für die Infos. Ich habe bei meinen Einstellungen noch nie etwas verändert. Wenn das so offen geregelt ist, und jeder es anders sieht, wundert es mich, dass es nicht häufiger Auseinandersetzungen um Änderungen nach Gusto am Leyout gibt. Gibt es nicht irgendeinen "Standard"?--Milseburg (Diskussion) 18:55, 19. Mai 2022 (CEST)

Ich kenne keinen und in all unseren „Regelungen“ steht auch immer nur „soll[t]en“ niemals wirst ein „muss so oder so“ finden. Es gibt nichts worauf du dich da berufen kannst. Ich (persönlich) würde es dort „hochkant“ einbinden. Und das hat weniger etwas mit „Gusto“ zu tun, als mit der Dominanz. Zu große Bilder lenken vom sehr viel wichtigeren Teil, nämlich dem Text = eigentlichen Artikelinhalt ab, (hier sieht es nicht einmal gut aus). Wer das größer ansehen möchte, der kann zur Bildbeschreibungsseite gehen oder den Medienbetrachter nutzen. Aber, wie gesagt, das empfindet jeder anders, für mich sieht der untere Bereich des Artikels alles andere als ansprechend aus, zum einen das links stehende Bild und dann das Bild (für mich) zu große unterhalb der Infobox. Ich hätte sie beide zusammen in gallery-Tags unter den Text gesetzt. Optisch zusammengehörig und weniger für unruhiges Layout sorgend = einladender für den Leser (meine Meinung). --Liebe Grüße, Lómelinde Diskussion 06:31, 20. Mai 2022 (CEST)

Es geht mir hier nicht darum, die Diskussion um die Steimwand zu führen. Ich wurde dort nur darauf aufmerksam gemacht, dass das Einfügen bzw. Weglassen des Parameters "hochkant" je nach Gerät und Einstellung zu vorteilhaften oder unvorteilhaften Änderungen am Leyout kommt. Daher wäre auf der Vorderseite eine klarere Empfehlung wünschenswert, die es Bearbeitern ermöglicht, die Parameter so einzustellen, dass es auch auf anderen Geräten als den eigenen zu einer guten Darstellung kommt. Ich steuere in WP viele Bilder bei und binde sie ein. Ich habe bisher nie darauf geachtet, ob sich meine Einbindungen auch auf anderen Geräten gut machen. Daher mein Wunsch nach mehr Klarheit. --Milseburg (Diskussion) 19:17, 20. Mai 2022 (CEST)

Nochmal da bist du hier falsch, die Hilfeseite beschreibt lediglich wie man Bilder einbinden kann, also die technischen Grundlagen der Einbindung an sich. Wie das in Artikeln verwendet werden soll gehört wenn dann zur Seite Wikipedia:Artikel illustrieren. Jeder empfindet es anders, was vorteilhaft oder unvorteilhaft ist. Das hängt von persönlichen Einstellungen, benutztem Endgerät, Browser, Bildschirmeinstellungen, Skin und … ab. Die Hilfeseite beschreibt die Technik, „wie binde ich ein Bild in eine Seite ein“ oder „wie ändere ich das Format“, „welche Möglichkeiten der Einbindung gibt es“. Es kann keine klare Empfehlung geben, Bilder sind auch unterschiedlich groß und davon hängt dann auch wieder ab, wie man sie einbindet. Sehr hohe und zugleich schmale Bilder sollten eher nicht als normales mini-Bild eingebunden werden. Gleiches gilt für sehr breite Bilder mit geringer Höhe (Panoramen). Wie man sie einbindet, das steht auf dieser Hilfesite beschrieben, das bedeutet aber nicht zwangsläufig, dass alle Bilder genau so eingebunden werden müssen, nur dass es diese Technik gibt. --Liebe Grüße, Lómelinde Diskussion 07:35, 21. Mai 2022 (CEST)

Ich zitiere den ersten Satz auf der Vorderseite: "Diese Seite erklärt, wie Du Bilder, Grafiken und Karten in Artikel einfügst und platzierst." Du schreibst, dass diese Seite lediglich beschreibt, wie man das machen kann. Ob mit oder ohne Modalverb ist entscheidnd für das Verständnis. Das eine ist es eine klare Empfehlung, das andere bloß eine Auflistung der Möglichkeiten. Also evtl. den ersten Satz änden in "Diese Seite erklärt, wie Du Bilder, Grafiken und Karten in Artikel einfügen und platzieren kannst." --Milseburg (Diskussion) 12:14, 21. Mai 2022 (CEST)

mini oder thumb

Ich habe irgendwann gelernt (und, wenn ich nicht irre, hier in Wikipedia, nicht draußen in der Wildnis), dass man Bilder mit "thumb" einbinden soll, nicht mit "mini". Jetzt wurde mir thumb nach mini korrigiert. Hat sich da die Sprachpolitik irgendwann geändert und ich habe was nicht mitbekommen?--Cabanero (Diskussion) 18:05, 28. Dez. 2022 (CET)

Nein, es ist beides richtig und beides möglich und so steht es auch auf der Hilfeseite. siehe Hilfe:Bilder#Grundlegendes Zitat: „Der zweite Parameter legt die Darstellungsart fest (hier ein Vorschaubild). Anstatt mini geht auch miniatur bzw. thumb.“

Üblicher ist hier bei uns das mini

thumb 58263 + thumbnail 238 = 58501

mini 249621 + miniatur 143141 = 492762

Es ist aber verständlicher, wenn es innerhalb eines Projekts einheitlich gemacht wird. Wie du sehen kannst wird mini/miniatur 8 mal so häufig verwendet.

Das thumb resultiert oftmals aus Übersetzungen aus der englischsprachigen Version. Die französische Version verwendet vignette und die italienische miniatura, andere Sprachversionen wieder andere Attribute. --Liebe Grüße, Lómelinde Diskussion 06:37, 29. Dez. 2022 (CET)

Problem mit der Darstellung von Bildern

Hallo zusammen, ich habe ein Darstellungsproblem bei verschiedenen Bildern. Problembeschreibung siehe unter Wikipedia:Auskunft#Hilfe - Bilder werden nicht richtig angezeigt. Es wäre super, wenn irgendjemand von den Bilderexperten hier einen Tipp geben könnte, wie man das Problem behebt. Antworten am besten in der Auskunft. Vielen Dank! LG Stefan 21:30, 13. Feb. 2023 (CET)

@Dionysos1988 Dein Problem betrifft aber keine Bilder in der Wikipedia, oder? In der Auskunft fragst du nach einem Bild auf einem externen Dienst. --Raymond ^Disk. 21:57, 13. Feb. 2023 (CET)

Das ist richtig, es geht um externe Bilder. Ich habe hier nur darauf aufmerksam gemacht, weil ich davon ausging, dass hier mehr Leute mit Ahnung mitlesen. :-) LG Stefan 22:02, 13. Feb. 2023 (CET)

@Dionysos1988 Okidoki. --Raymond ^Disk. 22:32, 13. Feb. 2023 (CET)