Wikipedia:Umfragen/Technische Wünsche 2017/Mediendateien

Umfrage Technische Wünsche 2017

Rubrik „Mediendateien“

Lesen  •   Suchen  •   Bearbeiten  •   Wartung  •   Beobachten & Benachrichtigen  •   Soziales  •   Schwesterprojekte  •   Mediendateien  •   Projekte ehrenamtlicher Entwickler  •   Sonstiges

Bitte nicht mehr abstimmen - diese Umfrage ist abgeschlossen. Herzlichen Dank an alle, die Vorschläge eingereicht, abgestimmt und die Umfrage mit fachlichem Rat begleitet haben.

Automatische Konvertierung auf freie Formate

Was ist das Problem?

Man kann nur offene Formate im Video/Audio-Bereich hochladen. Das Umwandeln ist je nach vorhandener Technik umständlich und tlw. nicht einfach.

Wen betrifft das Problem besonders?

Einsteiger, aber eigentlich jeden.

Lösungsvorschlag

Der Server konvertiert selber, die Quelldatei wird dabei nur temporär gespeichert und nur das offene Format geht online.

Hinweis von anderem Wikier in der Diskussion

"Der direkte Einbau in den Upload-Wizard wäre wünschenswert, weil niemand dieses Tool kennt. Soweit ich das sehe ist das im Upload-Wizard deaktiviert auf Grund von Patent-Zeugs. Das sollte sich aber noch mal jemand genauer ansehen, da die Lizenzkosten jedenfalls für H.264 wohl nicht für das Konvertieren, sondern nur für das Ausliefern anfallen. Und auch beim Ausliefern der Videos (H.264) scheinen Lizenzkosten nur dann anzufallen, wenn die Videos nicht frei Zugänglich sind, sie also hinter einer Paywall o.ä. sind. Dies trifft auf die Wikipedia ja nicht zu. Sollte sich am Besten mal ein Patent-Jurist ansehen, aber ich glaube, dass hier beschrenkungen eingebaut worden sind, ohne dass es wirklich nötig wäre. (Bezieht sich jetzt alles auf H.264 und beruht auf diese Stackexchange Frage) Ubahnverleih (Diskussion) 14:51, 11. Jun. 2017 (CEST) "

Anmerkungen

Konvertiert wird eh, für verschiedene formate und Größen

Vorschlagende Person

Dirk1981 (Diskussion) 13:50, 29. Mai 2017 (CEST) Dirk1981 (Diskussion) 13:50, 29. Mai 2017 (CEST)

Diskussion

Für Videos gibt es bereits das Tool https://tools.wmflabs.org/videoconvert/index.php, für Audio-Dateien ist geplant MP3 in Kürze direkt zu erlauben. –Schnark 08:55, 30. Mai 2017 (CEST)

Danke, Schnark! @Dirk1981: Wäre der Wunsch damit für dich erledigt? Wenn ja, würden wir den Wunsch nach Wikipedia:Umfragen/Technische_Wünsche_2017/Bereits_umgesetzte_Wünsche verschieben. -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 14:14, 7. Jun. 2017 (CEST)

Der direkte Einbau in den Upload-Wizard wäre wünschenswert, weil niemand dieses Tool kennt. Soweit ich das sehe ist das im Upload-Wizard deaktiviert auf Grund von Patent-Zeugs. Das sollte sich aber noch mal jemand genauer ansehen, da die Lizenzkosten jedenfalls für H.264 wohl nicht für das Konvertieren, sondern nur für das Ausliefern anfallen. Und auch beim Ausliefern der Videos (H.264) scheinen Lizenzkosten nur dann anzufallen, wenn die Videos nicht frei Zugänglich sind, sie also hinter einer Paywall o.ä. sind. Dies trifft auf die Wikipedia ja nicht zu. Sollte sich am Besten mal ein Patent-Jurist ansehen, aber ich glaube, dass hier beschrenkungen eingebaut worden sind, ohne dass es wirklich nötig wäre. (Bezieht sich jetzt alles auf H.264 und beruht auf diese Stackexchange Frage) Ubahnverleih (Diskussion) 14:51, 11. Jun. 2017 (CEST)

@Dirk1981: Könntest du die Hinweise von Ubahnverleih noch bei „Was ist das Problem?“ einbauen? Das scheint mir eine sinnvolle Ergänzung zu sein, aber die Diskussionen werden mit Beginn der Abstimmung (19. Juni) ausgeblendet. -- Beste Grüße, Johanna Strodt (WMDE) (Diskussion) 20:00, 15. Jun. 2017 (CEST)

Also ich sehe das nicht auf Videos/Tondateien beschränkt, statisches GIF oder BMP oder... bekommt merklichen Qualtätsschub durch eine Umwandlung auf PNG. -- User: Perhelion 16:03, 23. Jun. 2017 (CEST)

Unterstützung

1.  Pro Dirk1981 (Einreichende Person)
2.  Pro --Till.niermann (Diskussion) 20:54, 20. Jun. 2017 (CEST)
3.  Pro -- Michi 19:48, 21. Jun. 2017 (CEST)
4.  Pro -- Anguish (Diskussion) 23:36, 21. Jun. 2017 (CEST)
5.  Pro --Jossi (Diskussion) 14:01, 22. Jun. 2017 (CEST)
6.  Pro --GodeNehler (Diskussion) 23:16, 22. Jun. 2017 (CEST)
7.  Pro Auch Bildateien sind Mediendateinen auch wenn das in der Anfrage gar nicht zum Rede kommt, daher Kmt dort. -- User: Perhelion 16:03, 23. Jun. 2017 (CEST)
8.  Pro -- Freddy2001 ^DISK 12:20, 24. Jun. 2017 (CEST)
9.  Pro Viel mehr Videos würden hochgeladen, wenn die Umwandlung einfacher ginge. --Klaaschwotzer (Diskussion) 17:31, 24. Jun. 2017 (CEST)
10.  Pro Video/Audio/Bilder sind dann zu betrachten Divof (Diskussion) 20:22, 24. Jun. 2017 (CEST)
11.  Pro --Friedel Völker (Diskussion) 19:20, 27. Jun. 2017 (CEST)
12.  Pro --Thomas Obermair 4 (Diskussion) 17:17, 28. Jun. 2017 (CEST)
13. Enthaltung Nicht umwandeln, sondern für den Leser rendern (ähnlich SVG -> PNG; Math -> PNG; für TIFF und PDF gibts so was auch schon), die Mediendatei an sich muss so erhalten bleiben (keine Originaldateien "berühren"). --Gr1 (Diskussion) 22:44, 28. Jun. 2017 (CEST)
14. Enthaltung Schließe mich der Meinung von Gr1 an. --Snurb3010 (Diskussion) 22:02, 29. Jun. 2017 (CEST)
15.  Pro --Sebastian Wallroth 13:55, 30. Jun. 2017 (CEST)
16.  Pro -- Mboesch (Diskussion) 11:54, 1. Jul. 2017 (CEST)
17.  Pro —DerHexer (Disk., Bew.) 23:29, 1. Jul. 2017 (CEST)
18.  Pro --Boehm (Diskussion) 09:40, 2. Jul. 2017 (CEST)
19.  Pro -- Mr N (Diskussion) 23:29, 2. Jul. 2017 (CEST)
    
    

Vereinfachen des Hochladens von Bildern und deren Verlinken mit einem Artikel über das Handy oder Tablet (mobile Browser bzw. Apps)

Was ist das Problem?

Ich beschäftige mich erst seit Kurzem mit Wikipedia und Wikimedia Commons und würde sehr gerne Bilder hochladen und mit Artikeln verlinken. Im Urlaub und wenn ich unterwegs bin, wäre das eine schöne Beschäftigung. Leider geht das nur mit einen Computer "relativ" gut, jedoch mit einem Handy oder Tablet ist es eine qualvolle Erfahrung.

Ich habe zwei Wege ausprobiert: über mobile Browser und über die Apps (Wikipedia App, Wikimedia Commons App).

Ich habe lange nicht begriffen, dass man Bilder erst in Wikimedia (Wikimedia Commons App) hochladen muss und dann in Wikipedia verlinken. Dafür muss man sich beim Wechsel von einer App in die andere merken, wie das hochgeladene Bild hieß. Es ist nicht möglich die Bilder direkt in Wikipedia hochzuladen und zu verlinken. Sowohl das Hochladen in Wiki-Media als auch das Verlinken in Wiki-Pedia ist nicht intuitiv verständlich sondern muss durch mühsames ausprobieren herausgefunden werden (weder über mobile Browser noch über Apps). Mal muss man oben rechts, mal links klicken. Nichts ist standardisiert. Im mobilen Browser muss ich auch von der "mobilen Ansicht" auf "klassische Ansicht" wechseln und dann mit der "Spreizfingergeste" mühsam herumsuchen, bis ich es geschafft habe, das Bild zu verlinken. Teilweise muss ich mich sogar mit einer Pseudo-Code Sprache beschäftigen (Datei:xxx.jpg

Wen betrifft das Problem besonders?

Betroffen sind Benutzer, die wenig Erfahrung mit Wikipedia haben, die aber Spaß daran hätten, Bilder auf Wikipedia hochzuladen. Betroffen sind Benutzer, die gerne über mobile Geräte (Handy oder Tablet) arbeiten und nicht mit dem Computer.

Lösungsvorschlag

In der Wikipedia App sollte es möglich sein, Bilder hochzuladen. Das geht leider nur in der Wikimedia Commons App.

Außerdem sollten die Bilder automatisch mit einem Artikel verlinkt werden, ohne viel herumklicken.

Anmerkungen

Bitte verbessert die Apps (Wikipedia App und Wikimedia Commons App) zum vereinfachten Upload von Bildern über mobile Geräte!

Vorschlagende Person

Dede454 (Diskussion) 14:46, 29. Mai 2017 (CEST)

Diskussion

Hallo Dede454, danke für deinen Wunsch. Ich habe dazu eine kleine Anmerkung: Du meinst die App Wikimedia Commons, oder? Könntest du das in der Problembeschreibung entsprechend ändern? -- Danke und beste Grüße, Johanna Strodt (WMDE) (Diskussion) 14:10, 7. Jun. 2017 (CEST)

Unterstützung

1.  Pro Dede454 (Einreichende Person)
2.  Pro --FNDE 11:40, 20. Jun. 2017 (CEST)
3.  Pro --SkiFreak99 (Diskussion) 00:29, 21. Jun. 2017 (CEST)
4.  Kontra Fördert nur qualitativ schlechtes Bildmaterial. -- Freddy2001 ^DISK 12:21, 24. Jun. 2017 (CEST)
5.  Kontra Birgt die Gefahr zumindest eines fröhlichen Bilderüberfrachtens von Artikeln wenn nicht eines "Bilder-Vandalismus". --Eweht
6.  Pro --Thomas Obermair 4 (Diskussion) 17:17, 28. Jun. 2017 (CEST)
7.  Pro Mobile Nutzung ist wichtig --Snurb3010 (Diskussion) 22:05, 29. Jun. 2017 (CEST)
8.  Pro --Sebastian Wallroth 13:56, 30. Jun. 2017 (CEST)
   
   

Überarbeitung des Video- und Musikplayers

Was ist das Problem?

In meinen Augen sieht das Design des Video- bzw. Musikplayers sehr "altbacken" aus und ist nicht wirklich einladend.

Wen betrifft das Problem besonders?

Angemeldete Benutzer. Autoren, Sichter und Admins.

Lösungsvorschlag

Ein moderneres Design ist hier recht schnell zu errichten per HTML und CSS (eventuell PHP und JavaScript). Eine Anregung wie ich mir persönlich dies gut vorstellen könnte, liefert hier der Chrome Browser. Siehe hier: Design-Vorschlag

Vorschlagende Person

DerMeininger ✉ 15:43, 29. Mai 2017 (CEST)

Diskussion

Das passiert bereits, siehe phab:T100106 und die dort verlinkten Tasks. Auf https://de.wikipedia.beta.wmflabs.org/wiki/Wikipedia:Hauptseite kannst du den neuen Player bereits in den Beta-Einstellungen aktivieren, und es dauert wohl nicht mehr lange, bis das auch hier der Fall ist und der neue Player schließlich zum Standard wird. –Schnark 11:54, 30. Mai 2017 (CEST)

Lieber DerMeininger, wäre dein Wunsch damit gelöst? Dann würden wir den Wunsch umziehen in die Rubrik Wikipedia:Umfragen/Technische_Wünsche_2017/Bereits_umgesetzte_Wünsche. -- Beste Grüße, Johanna Strodt (WMDE) (Diskussion) 14:00, 7. Jun. 2017 (CEST)

Also eigentlich schon Johanna Strodt (WMDE), nur leider weiß ich bisher immer noch nicht auf welcher Seite ich mir den Player mal anschauen könnte.... Deswegen bisher bitte nicht.DerMeininger ✉ 17:41, 7. Jun. 2017 (CEST)

Korrigiere, konnte ihn mir nun anschauen. Sieht gut aus. Das einzigste was ich besser fände, wäre eine Helle Player Optik. Aber ansonsten sehr modern. Vielen Dank an die Entwickler. Damit kann das Anliegen verschoben werden - vorausgesetzt an meinem Vorschlag zur Hellen Player Optik lässt sich was machen. DerMeininger ✉ 17:58, 7. Jun. 2017 (CEST)

Hallo DerMeininger, freut mich, dass dir der neue Player gefällt! Wegen der Hellen Player Optik: Könntest du den Wunsch dann noch daraufhin spezifizieren? - Möglichst bis Sonntagnachmittag, weil die Abstimmung am Montag beginnt. Falls du einen Phabricator-Account hast, könntest du alternativ diesen Verbesserungsvorschlag auch bei den Entwicklern des Players direkt einbringen & wir könnten ihn dann hier verschieben. Viele Grüße, --Birgit Müller (WMDE) (Diskussion) 17:40, 16. Jun. 2017 (CEST)

Dein Designvorschlag ist der native Player von Google Chrome. Dieser würde auch benutzt werden, wenn MediaWiki da nicht einen eigenen nutzen würde. -- Freddy2001 ^DISK 12:22, 24. Jun. 2017 (CEST)

Unterstützung

1.  Pro DerMeininger (Einreichende Person)
2.  Pro --HerrAdams (D) 18:52, 20. Jun. 2017 (CEST)
3.  Pro (nicht signierter Beitrag von Ziko (Diskussion | Beiträge) )
4.  Pro -- Michi 19:48, 21. Jun. 2017 (CEST)
5.  Pro --GodeNehler (Diskussion) 23:16, 22. Jun. 2017 (CEST)
6.  Pro -- Freddy2001 ^DISK 12:22, 24. Jun. 2017 (CEST)
7.  Pro --Merlin2001 (Diskussion) 10:40, 28. Jun. 2017 (CEST)
8.  Pro --Thomas Obermair 4 (Diskussion) 17:18, 28. Jun. 2017 (CEST)
9.  Pro Ob schön oder nicht schön ist nicht entscheidend. Wichtig ist eine gute Bedienbarkeit, auch auf mobilen Geräten. Der Designansatz geht in diese Richtung. --Snurb3010 (Diskussion) 22:10, 29. Jun. 2017 (CEST)
10.  Pro KPFC 💬 22:55, 29. Jun. 2017 (CEST)
11.  Pro --Morten Haan 🎲 Wikipedia ist für Leser da • Skin-Entwurf 01:07, 30. Jun. 2017 (CEST)
12.  Pro --C₂₁H₂₂N₂O₂ (Diskussion) 22:30, 2. Jul. 2017 (CEST)
13.  Pro wobei ich auf eine weitverbreiteten Medientyp hinweisen möchte der momentan katastrophal unterstützt wird trotz weiterhin überragender Beduetung: das GIF Animationsformat. Hierzu den mehrfach bereits aufgekommen Vorschlag den Support mit einem Player mit Kontrollmöglichkeiten zu verbessern Shaddim (Diskussion) 12:08, 9. Jul. 2017 (CEST)
    
    

Popupfenster für Landkarten

Was ist das Problem?

Zum Verständnis der Beschreibung eines geografischen Objektes ist es oftmals angebracht, dieses mit einer Landkarte zu illustrieren, in der die relevanten Details und Namen wesentlich besser zu erkennen sind als z. B. in Openstreetmap. Damit sie gut zu erkennen sind, muss die Karte wesentlich größer eingeblendet werden, als in einer Breite von 200 px. Wenn der Leser die Landkarte in einem separaten Fenster öffnet, behindern dessen breite Navigationsränder das gleichzeitige Betrachten von Text und Karte.

• ein Beispiel, das zeigt, wo das beschriebene Problem besonders stark auftritt: Donau – Die Karte aus der Infobox bräuchte man gleich zu mehreren Kapiteln.

Wen betrifft das Problem besonders?

Autoren und Leser

Lösungsvorschlag

Ein quasi randloses Popupfenster (mit vom Autor festzulegender Breite, evt. auch zwei Breiten, aus denen der Leser sich nach seiner Bildschirmgröße eine auswählen kann (Bei Rastergrafiken git es allgemein gute Darstellungsgrößen mit klaren Konturen, dazwischen weniger geeignete, die verschmiert aussehen)) kann es ermöglichen, Text und Karte gleichzeitig vor Augen zu haben und natürlich bei einem längeren Text die Illustration mitzuziehen.

Optimal wäre eine Kombination dieses schwebenden Popup-Fensters mit dem Vorschlag #Lupenfunktion für große Bilder (vor allem Landkarten), um gleichzeitig Details vergrößern zu können bzw. nur Ausschnitte der Karte zu sehen. --Fährtenleser (Diskussion) 07:40, 11. Jun. 2017 (CEST)

Anmerkungen

• So ein Popupfenster sollte durch Klicken auf ein Vorschaubild (200 px oder kleiner, Größenfestlegung durch den Autor) aufzurufen sein.
• Es lässt sich natürlich auch für andere Grafiken nutzen, z. B. Flussdiagramm, oder hochaufgelöste Fotos, z. B. Gebäudefassade
  Vorschlagende Person

Ulamm (Kontakt) 18:22, 29. Mai 2017 (CEST)

Diskussion

@Ulamm: Danke für deinen Vorschlag! Könntest du vielleicht noch ein Beispiel verlinken, was zeigt, wo das beschriebene Problem besonders stark auftritt? Das wäre super! Viele Grüße, Lea Voget (WMDE) (Diskussion) 15:13, 30. Mai 2017 (CEST)

Donau – Die Karte aus der Infobox bräuchte man gleich zu mehreren Kapiteln.--Ulamm (Kontakt) 16:07, 30. Mai 2017 (CEST)

@Ulamm: Danke. Ich war so frei, das Beispiel in deinem Wunsch zu ergänzen, denn die Diskussion wird zu Beginn der Abstimmung (ab 19. Juni) ausgeblendet, damit klar ist, worauf abgestimmt wird. Falls in der Diskussion noch andere Hinweise stecken, die für das Verständnis des Wunsches hilfreich sind, arbeite sie am besten auch in den Wunsch selbst ein. -- Beste Grüße, Johanna Strodt (WMDE) (Diskussion) 16:33, 10. Jun. 2017 (CEST)

ich bin nur user und kenne die technischen Grundlagen nicht, aber es gibt auf Webseiten manchmal ein kleines Fenster, dass fixiert ist (oder immer nach oben rutscht), auch wenn man nach unten scrollt. Diese Funktion für Bilder (gleich ob Fotos oder Karten) in Artikeln wäre fein. Entweder das Fenster ist fix rechts (oder links) oben, besser wäre eine beliebige Anordnung. edit: dieses kleine Fenster könnte auch die Lupenfunktion übernehmen (siehe unten). Erfahrungsgemäß wird das Verwirklichen solcher Dinge aber immer schwieriger, je mehr die Funktion „kann“ (vermute ich mal). lG --Hannes 24 (Diskussion) 12:51, 7. Jun. 2017 (CEST)

Ich habe mal den Vorschlag von @Johanna Strodt (WMDE):, diese Idee und meine mit der Lupenfunktion für große Bilder/Landkarten zu verbinden, hier kurz mit eingefügt. Lieber @Ulamm:, ich hoffe, das war o.k.? --Fährtenleser (Diskussion) 07:50, 11. Jun. 2017 (CEST)

Formatierung durch Autor, Anpassung durch Nutzer:

• Als Einstiegsformat wird der/die Autor/in eher eine Aufösung und eine Rahmengröße wählen, bei der möglichst viel zu lesen UND möglichst viel abgebildet ist.
• Ein kleines Steuerfeld in einer Ecke sollte allerdings dem/der Lerser/in die Möglichkeit geben, hinein- oder hinauszuzoomen.

Auf diese Weise entsteht einerseits eine Lupenfunktion und andererseits die Möglichkeit, als Einstiegsformat einen besonders interessanten Ausschnitt zu wählen, z. B. das Schloss in einem Schlosspark, die Altstadt in einem Stadtplan.

Falls es möglich wird, einen Ausschnitt als Einstiegsformat zu wählen, sollte die Formatierung allerdings von den Autoren keine fortgeschrittenen Programmierkenntnisse verlangen. Bei Rastergrafiken kann das recht einfach gelingen, wenn der Pixelabstand der linken oberen Ecke und der rechten unteren Ecke des Einstiegsausschnitts von der linken oberen Ecke der Gesamtgrafik einzugeben sind. ohne diese Zusatzeingabe soll das Einstiegsformat die Gesamtgrafik umfassen.

Mit der Möglichkeit der Darstellung eines Ausschnitts ergibt sich allerdings eine weitere Anforderung: Der/die Leser/in soll unabhängig voneinander das Popup-Fenster auf dem Bildschirm verschieben können und den hineingezoomten Ausschnitt innerhalb der Grafik.

Meinetwegen:

• das Verschieben des Fensters mittels Anklicken und Verschieben des Randes,
• das Hineinzoomen mit einem Klick auf ein PLUS in einer Ecke und dann einem Klick in die Mitte des in Vergrößerung gewünschten Bereiches.
• Die Lupe innerhalb der Grafik verschieben kann man dann durch Klicken in die Fläche und Bewegen des Cursors während gehaltener Maustaste. --Ulamm (Kontakt) 20:09, 15. Jun. 2017 (CEST)

Unterstützung

1.  Pro Ulamm (Einreichende Person)
2.  Pro Jeb (Diskussion) 07:00, 20. Jun. 2017 (CEST)
3.  Pro --FNDE 11:41, 20. Jun. 2017 (CEST)
4.  Pro Jordi (Diskussion) 15:17, 20. Jun. 2017 (CEST)
5.  Pro --Fährtenleser (Diskussion) 16:20, 20. Jun. 2017 (CEST)
6.  Pro --Till.niermann (Diskussion) 20:55, 20. Jun. 2017 (CEST)
7.  Pro --Jossi (Diskussion) 14:02, 22. Jun. 2017 (CEST)
8.  Pro --GodeNehler (Diskussion) 23:17, 22. Jun. 2017 (CEST)
9.  Pro --Lencer (Diskussion) 13:56, 27. Jun. 2017 (CEST)
10.  Pro --Pechristener (Diskussion) 20:53, 27. Jun. 2017 (CEST)
11.  Pro --Merlin2001 (Diskussion) 10:49, 28. Jun. 2017 (CEST)
12.  Pro --Thomas Obermair 4 (Diskussion) 17:18, 28. Jun. 2017 (CEST)
13.  Pro -- Mboesch (Diskussion) 11:55, 1. Jul. 2017 (CEST)
    
    

Handling von GPX-Dateien in Wikimedia-Projekten

Was ist das Problem?

Darstellung von Routen, u.a. in Wikivoyage

• Was möchtest du machen und warum? Darstellung von Routen (Wanderrouten, Bikerouten, Stadtrundgängen, Rundgängen in ärchäologischen Geländen) in integrierten dynamnischen Karten
• Welche Schritte durchläufst du dabei? Mit dem Wechsel auf die Wikimedia - Karten ist das Handling von Routen für mich sehr schwierig geworden, da GPX-Files nicht genuin unterstützt werden.
• Welche Probleme treten auf? Wanderrouten können nicht mehr angezeigt werden, es muss viel mehr mit Wegbeschreibungen und POI / Markern gearbeitet werden (bei der nächten Kreuzung links, über die Brücke (hier Marker setzen), dann bei der Verzweigung rechts..., und so weiter). Bei kommerziellen Projekten, Wanderwebsites, etc. kann direkt die Route auf einer Popup-Karte angezeigt werden, was in VW vor der Ära der Wikimedia-Karten noch ging.

GPX-Files können einfach vom Smartphone oder Wandernavi erstellt werden, was die Ausarbeitung von Tourenvorschlägen vor allem in Weltgegenden ohne markiertes gutes Wanderwegnetz massiv vereinfacht (mal in Sizilien gewandert... mit Messtischkarten aus den Fünfzigern und Google Maps als Overlay...).

Wen betrifft das Problem besonders?

Autoren und User von Wikivoyage

Lösungsvorschlag

Genuine Unterstützung von GPX zur Darstellung in den Wikimedia-Karten.

Anmerkungen

Wäre wohl auch hilfreich für Wikipedia, wenn Streckenverläufe von Bahnlinien, etc. einfach als GPX-Files erfasst und auf den Karten angezeigt werden könnten.

Vorschlagende Person

Mboesch (Diskussion) 22:21, 29. Mai 2017 (CEST)

Diskussion

Nicht GPX, aber kennst du schon den Datentyp "geo-shape" auf Commons? Beispiele: c:Data:Inner West Light Rail stops.map, c:Data:Sandbox/Gareth/Georges River Council.map, c:Data:IsraelHighways/44.map. --тнояsтеn ⇔ 14:01, 30. Mai 2017 (CEST)

Danke für den Hinweis, vor allem die Highway map sieht so aus, wie wir es brauchen. Auf WV gab es schon einen Vorschlag, das so umzusetzen, es war für mich aber zu komplex, habe mich allerdings auch noch nicht eingelesen, wie man die Dateien erstellt. GPX wäre halt weitverbreitet, praktisch alle Kartensoftwaren können zumindest nach GPX exportieren und die Navis zeichnen in dem Format auf, mit Smartphone-Apps habe ich zu wenig Erfahrung als Wenignutzer, whs. wäre auch von dort her die direkte Erstellung eines Track möglich - die Hürden für den User zum Upload sollen letztendlich möglichst niedrig sein, wir wollen ihn zur Mitarbeit bei WV / WP gewinnen und nicht bei einem kommerziellen Wanderportal, wohin er direkt sein GPX-File hochladen kann. Lg Martin - Mboesch (Diskussion) 20:25, 30. Mai 2017 (CEST)

@Mboesch: Danke für deinen Vorschlag! Bei der Abstimmung wird die Diskussion eingeklappt, damit klar ist, worüber abgestimmt wird. Wenn Hinweise aus der Diskussion für deinen Wunsch hilfreich sind (auch deine Antworten auf Rückfragen), wäre es gut, wenn du sie oben – z. B. unter „Was ist das Problem?“ oder „Lösungsvorschlag“ – ergänzt. Das geht noch bis zum 19. Juni. -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 19:11, 8. Jun. 2017 (CEST)

Unterstützung

1.  Pro Mboesch (Einreichende Person)
2.  Pro --Fährtenleser (Diskussion) 16:23, 20. Jun. 2017 (CEST)
3.  Pro --Alturand (Diskussion) 21:28, 21. Jun. 2017 (CEST) Außer die Kartenwerkstatt hätte noch genügend freie Kapazitäten, solche Karte zu erstellen und zu pflegen...
4.  Pro --GodeNehler (Diskussion) 23:17, 22. Jun. 2017 (CEST)
5.  Pro im Sinne von automatischer Konvertierung von GPX zu geo shapes phab:T55023. --El Grafo _(COM) 09:00, 23. Jun. 2017 (CEST)
6.  Pro -- Freddy2001 ^DISK 12:22, 24. Jun. 2017 (CEST)
7.  Pro --Eweht (Diskussion)
8.  Pro --Pechristener (Diskussion) 20:56, 27. Jun. 2017 (CEST)
9.  Pro --Merlin2001 (Diskussion) 10:51, 28. Jun. 2017 (CEST)
10.  Pro --Thomas Obermair 4 (Diskussion) 17:19, 28. Jun. 2017 (CEST)
11.  Pro KPFC 💬 22:56, 29. Jun. 2017 (CEST)
12.  Pro Wäre sehr nützlich für Wikivoyage und eventuell kombinierbar mit Ideen aus en:Wikipedia:Smart city uses of Wikipedia. Auch könnte man das mit geolokalisierten Wikipedia-Artikeln kombinieren. Beispielsweise für die personalisierte Erstellung von Stadtbesichtigungstouren! --Fixuture (Diskussion) 23:14, 1. Jul. 2017 (CEST)
    
    

Dynamische Karten über OpenStreetMap Daten.

Was ist das Problem?

Karten wie z.b.

sollten aus OSM-Daten über eine Abfrage generiert werden, oder ein Befehl über Wikidata, oder einer Geojson Datei. Da ich selbst solche .svg "Verwaltungskarten" ab und an erstelle und das auch immer aus OSM-Grenzrelationen, die Grenzen aber teils auch nicht sehr genau eingetragen sind, wäre es eine Erleichterung, wenn sich eine Karte automatisch den neuen Gegebenheiten anpassen würde, wenn irgendjemand die Grenzen in OSM dochmal verbessert.

Wen betrifft das Problem besonders?

Alle die sich mit Karten beschäftigen.

Lösungsvorschlag

Hier wurde schon was gestartet, sollte aber vervollständigt und aktiv unterstützt werden.

https://www.mediawiki.org/wiki/Maps/Conversation_about_interactive_map_use

Vorschlagende Person

Kenji (Diskussion) 22:39, 29. Mai 2017 (CEST)

Diskussion

Hallo Kenji, zum besseren Verständnis des Wunsches wäre es cool, wenn du darauf eingehen könntest, warum du dir das wünschst. Z.B. wie ist der Status Quo und was ist daran störend? -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 12:30, 30. Mai 2017 (CEST)

Da ich selbst solche .svg "Verwaltungskarten" ab und an erstelle und das auch immer aus OSM-Grenzrelationen, die Grenzen aber teils auch nicht sehr genau eingetragen sind, wäre es eine Erleichterung, wenn sich eine Karte automatisch den neuen Gegebenheiten anpassen würde, wenn irgendjemand die Grenzen in OSM dochmal verbessert. --Kenji (Diskussion) 22:43, 30. Mai 2017 (CEST)

Danke, Kenji. Ich hab deinen Kommentar unter „Was ist das Problem?“ ergänzt, weil die Diskussion mit Beginn der Abstimmung ausgeblendet wird. -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 13:52, 7. Jun. 2017 (CEST)

Bei Grenzdarstellungen wäre ich immer vorsichtig, so was zu automatisieren. Das sollte ganz in der Hand erfahrener Kartographen liegen. Über das Positionskartenprojekt haben wir festgestellt, dass es immer wieder Probleme mit Leuten gibt, die die Darstellung politisch brisanter Grenzlinien durchsetzen wollen. Denen würde eine Hintertür über OSM geöffnet werden, wenn ich diesen Wunsch richtig verstehe. Grüße Lencer (Diskussion) 14:08, 27. Jun. 2017 (CEST)

Unterstützung

1.  Pro Kenji (Einreichende Person)
2.  Pro Jeb (Diskussion) 07:01, 20. Jun. 2017 (CEST)
3.  Pro --Fährtenleser (Diskussion) 16:32, 20. Jun. 2017 (CEST)
4.  Pro Hermannh (Diskussion) 21:58, 20. Jun. 2017 (CEST)
5.  Pro --Trockennasenaffe (Diskussion) 09:24, 21. Jun. 2017 (CEST)
6.  Pro Conny 13:57, 21. Jun. 2017 (CEST).
7.  Pro sk (Diskussion) 16:59, 21. Jun. 2017 (CEST)
8.  Pro -- Anguish (Diskussion) 23:38, 21. Jun. 2017 (CEST)
9.  Pro --TypeZero (Diskussion) 17:46, 22. Jun. 2017 (CEST)
10.  Pro -- Freddy2001 ^DISK 12:23, 24. Jun. 2017 (CEST)
11.  Kontra Siehe Disk. --Lencer (Diskussion) 14:08, 27. Jun. 2017 (CEST)
12.  Pro --Friedel Völker (Diskussion) 19:22, 27. Jun. 2017 (CEST)
13.  Pro --Merlin2001 (Diskussion) 10:56, 28. Jun. 2017 (CEST)
14.  Pro --Thomas Obermair 4 (Diskussion) 17:19, 28. Jun. 2017 (CEST)
15.  Pro. Sollte aber optional sein und die bisherige Praxis weiterhin möglich bleiben. Z. B. bei umstrittenen Grenzen, gewünscht alten oder abweichenden Grenzverläufen und anderem könnte man ggf. per Konvention diese OSM-Karten ausschließen. -- X:: black ::X (Diskussion) 21:14, 2. Jul. 2017 (CEST)
    
    

Kartenerstellung vereinfachen

Was ist das Problem?

Wenn es z.B. zum Anschlag kommt ist es ab und an schwer, eine Karte einzufügen. Die Funktion Location map braucht immer ein Template. Und ab und an gibt es keine Map Template für diese.

Wen betrifft das Problem besonders?

Normale Nutzer*innen

Lösungsvorschlag

Ein erleichtertes Einfügen von Karten durch OpenStreetMap Funktion. Dort gibt es nämlich Karten, wenn man darauf einfach zurückgreifen könnte, wäre das toll!

Vorschlagende Person

Rævhuld (Diskussion) 16:25, 30. Mai 2017 (CEST)

Diskussion

Evtl. per direkter Einbindung von OSM? --FNDE 11:43, 20. Jun. 2017 (CEST)

• en.wikivoyage hat was in der Art: voy:en:Wikivoyage:How to use dynamic maps, voy:en:Template:Mapframe, voy:en:Module:Map. --El Grafo _(COM) 09:05, 23. Jun. 2017 (CEST)

Unterstützung

1.  Pro Rævhuld (Einreichende Person)
2.  Pro --FNDE 11:43, 20. Jun. 2017 (CEST)
3.  Pro --SkiFreak99 (Diskussion) 00:30, 21. Jun. 2017 (CEST)
4.  Pro (nicht signierter Beitrag von Ziko (Diskussion | Beiträge) 16:11, 21. Juni 2017 (CEST))
5.  Pro --Thomas Obermair 4 (Diskussion) 17:19, 28. Jun. 2017 (CEST)
   
   

Rendern von SVG verbessern

Was ist das Problem?

T36947

T35245

Viele Bugs. Auch als erfahrener Zeichner kämpft man bei jedem Bild mit den Zicken. Die nebenstehende Grafik hat zum Beispiel Probleme mit der Schrift. Der Zeichenabstand variiert sehr unregelmäßig.

Sammlung der Bugs

Wen betrifft das Problem besonders?

Jeder der Landkarten, technische oder wissenschaftliche Informationen bei Wikipedia nachliest. SVG ist das bevorzugte Format für hochwertige Zeichnungen. Zeichner von Grafiken, Erfahrene wie Einsteiger.

Lösungsvorschlag

Die schmerzhaftesten Bugs evaluieren und der Reihe nach beheben. Ein paar Themen wären

• phab:T36947, Bei großen Bilder sieht der Text des eingebundenen Bildes schlecht aus.
• phab:T35245, entsteht meist beim Kopieren von Diagrammen aus PDFs
• SVG2, da kommen bald neue und sehnsüchtig erwartete Features, nachdem sich seit 2003 nicht viel getan hat.
  Anmerkungen

Die Alternative zum Bugs beheben wäre die Evaluierung eines anderen SVG-Renderers (PhantomJS oder Inkscape).

Vorschlagende Person

Menner (Diskussion) 20:04, 30. Mai 2017 (CEST)

Diskussion

Hallo Menner, um den Wunsch einzugrenzen & planbar zu machen: Könntest du die Top 3 Bugs beschreiben und den Wunsch darauf eingrenzen? - das wäre super! Viele Grüße, --Birgit Müller (WMDE) (Diskussion) 17:16, 31. Mai 2017 (CEST)

Ergänzt. --Menner (Diskussion) 19:55, 4. Jun. 2017 (CEST)

Das sind aber intakte Textebenen in dem Beispiel, wie man sie beim händischen Malen in Inkscape erzeugt. Selbstverständlich sehen die schlecht aus, wenn man die Datein so hochlädt. Wenns gut aussehen soll, muss man sie in Pfade aufbrechen (Shift+Ctrl+C). Ansonsten müsste Wikipedia ja alle Schriftarten vorrätig halten... Alexpl (Diskussion) 19:40, 10. Jun. 2017 (CEST)

Texte als Pfad widersprechen dem Prinzip SVG. Es ist auch kein Problem der vorhanden Schriftarten. Es entsteht beim ganz normalen Skalieren für das Vorschaubild, oder eben bei unschönem SVG-code. Firefox&co machen es immer fehlerfrei und eigentlich gibt es sogar einen Patch. Ob der heute oder in fünf Jahren kommt hängt vom Update-Eifer ab. -- Menner (Diskussion) 12:35, 11. Jun. 2017 (CEST)

@Birgit Müller (WMDE): Wieso setzt man auf den Servern der WMF eigentlich nicht einfach einen Webbrowser als Renderer ein und lässt den einen Screenshot in der gewünschten Auflösung speichern? (Oder tut man das sogar?) Es gibt ja diverse Lösungen (wie z.B. Phantom.js (Webkit) mit denen sich sowas automatisieren liese?! Dann könnte man sicher gehen, dass das Resultat dem entspricht, was auch wir im entsprechenden Browser sehen, und könnte sich viel Arbeit sparen, weil man nicht mehr selbst hinter irgendwelchen Rendering-Features herhecheln müsste. Zusätzlich könnte man serverseitig neben den Linux-Systemfonts und den Standard Windowsfonts auch dieselben OpenSource-Schriften vorhalten, die auf Google-Fonts gehostet werden und somit einen Großteil der verwendeten Schriften abdecken. Ein eigenes Webfont-CDN hätte zudem den Vorteil, dass man diese Fonts auch mit der SVG-Anzeige selbst ausliefern könnte. So dass das SVG nicht nur als PNG, sondern auch in seiner Ursprungsform auf allen Endgeräten möglichst identisch aussieht. // Martin K. (Diskussion) 18:29, 20. Jun. 2017 (CEST)

@Birgit Müller (WMDE): Drei Bugs die mich nerven:

• in unterschiedlichen Dateigrößen unterschiedlich lange Schrift: Wikipedia:Grafikwerkstatt#Flugzeugentf.C3.BChrung
• Wikipedia:Probleme_mit_SVGs#An_Pfad_ausgerichteter_Text als auch Wikipedia:Probleme_mit_SVGs#Hoch-_und_tiefgesteller_Text
• <text font-family="'Liberation serif'"> sollte erkannt werden (macht Inkscape so mit "'...'", wiki erkennt nur '...' oder "..." alle drei sind gemäss https://validator.w3.org/check erlaubt und in Firefox und Chrome erkannt.)

@Antonsusi: Als aktivster in der WP:Grafikwerkstatt, was haltest du von der Idee.

 — Johannes Kalliauer - Diskussion | Beiträge 21:02, 21. Jun. 2017 (CEST)

Das liegt klar am Renderer. Besser wäre eine direkte Darstellung von SVGs, denn die Browser haben ja alle bessere Renderer als die WP-Server. ÅñŧóñŜûŝî (Ð) 19:42, 22. Jun. 2017 (CEST)

Mit Abstand die grösste Pest, ist dass das Rendering der Schriften nicht klappt. Der Umweg führt für mich nur noch über die Umwandlung aller Schriften in Pfade, was diese dann aber nicht mehr bearbeitbar macht. Eigentlich Schade.--Pechristener (Diskussion) 21:02, 27. Jun. 2017 (CEST)

Unterstützung

1.  Pro Menner (Einreichende Person)
2.  Pro  _hugarheimur 08:16, 20. Jun. 2017 (CEST)
3.  Pro --FNDE 11:43, 20. Jun. 2017 (CEST)
4.  Pro --Blik (Diskussion) 17:01, 20. Jun. 2017 (CEST)
5.  Pro // Martin K. (Diskussion) 18:18, 20. Jun. 2017 (CEST)
6.  Pro--Trockennasenaffe (Diskussion) 09:25, 21. Jun. 2017 (CEST)
7.  Pro -- Michi 19:51, 21. Jun. 2017 (CEST)
8.  Pro — Johannes Kalliauer - Diskussion | Beiträge 21:02, 21. Jun. 2017 (CEST)
9.  Pro -- Anguish (Diskussion) 23:39, 21. Jun. 2017 (CEST)
10.  Pro --Jü (Diskussion) 06:32, 22. Jun. 2017 (CEST)
11.  Pro --Jossi (Diskussion) 14:03, 22. Jun. 2017 (CEST)
12.  Pro -- ÅñŧóñŜûŝî (Ð) 19:23, 22. Jun. 2017 (CEST)
13.  Pro Als erkorener "Experte" hier kann ich sagen, es macht einfach keinen Spaß mehr. -- User: Perhelion 16:07, 23. Jun. 2017 (CEST)
14.  Pro -- Freddy2001 ^DISK 12:23, 24. Jun. 2017 (CEST)
15.  Pro --Ysangkok (Diskussion) 23:17, 24. Jun. 2017 (CEST)
16.  Pro --Boehm (Diskussion) 21:23, 25. Jun. 2017 (CEST)
17.  Pro --Lencer (Diskussion) 13:59, 27. Jun. 2017 (CEST)
18.  Pro NNW 16:32, 27. Jun. 2017 (CEST)
19.  Pro --Chumwa (Diskussion) 17:01, 27. Jun. 2017 (CEST)
20.  Pro --Incabell (Diskussion) 18:04, 27. Jun. 2017 (CEST)
21.  Pro --Friedel Völker (Diskussion) 19:22, 27. Jun. 2017 (CEST)
22.  Pro --Pechristener (Diskussion) 21:02, 27. Jun. 2017 (CEST)
23.  Pro --Merlin2001 (Diskussion) 12:47, 28. Jun. 2017 (CEST)
24.  Pro --Thomas Obermair 4 (Diskussion) 17:20, 28. Jun. 2017 (CEST)
25.  Pro --Flo Beck (Diskussion) 12:57, 29. Jun. 2017 (CEST)
26.  Pro -- Thoroe (Diskussion) 13:45, 29. Jun. 2017 (CEST)
27.  Pro für Inkscape als Renderer --Snurb3010 (Diskussion) 22:16, 29. Jun. 2017 (CEST)
28.  Pro KPFC 💬 22:57, 29. Jun. 2017 (CEST)
29.  Pro --Morten Haan 🎲 Wikipedia ist für Leser da • Skin-Entwurf 01:07, 30. Jun. 2017 (CEST)
30.  Pro --Sebastian Wallroth 13:57, 30. Jun. 2017 (CEST)
31.  Pro --ApolloWissen • bei Fragen hier 14:14, 30. Jun. 2017 (CEST)
32.  Pro -- Mboesch (Diskussion) 11:57, 1. Jul. 2017 (CEST)
33.  Pro —DerHexer (Disk., Bew.) 23:31, 1. Jul. 2017 (CEST)
34.  Pro -- X:: black ::X (Diskussion) 21:21, 2. Jul. 2017 (CEST)
35.  Pro -- - Majo Senf - ^{Mitteilungen an mich} 21:26, 2. Jul. 2017 (CEST)
36.  Pro -- Mr N (Diskussion) 23:39, 2. Jul. 2017 (CEST)
37.  Pro Shaddim (Diskussion) 12:02, 9. Jul. 2017 (CEST)
    
    

Bilder-Downloadlink für Breite 1920 bzw. Höhe 1080

Was ist das Problem?

Auf der Medienseite von Bildern, bzw. im Medienviewer, werden Downloadlinks mit verschiedenen Auflösungen angeboten. Keine davon ist auf einen 1920*1080 bzw. 1920*1200 Monitor ausgelegt, der derzeit wohl der Standard sein dürfte. 1024 ist aus meiner Sicht obsolet (wie auch die Vielfachen davon hinter dem Herunterladen-Link).

Wen betrifft das Problem besonders?

Benutzer, die gerne ein Wikipediabild als Bildschirmhintergrund nehmen möchten.

Lösungsvorschlag

1) Auf der Medienseite den Link hinzufügen

2) Im Medienviewer eine entsprechende Auflösung hinzufügen (dort wird derzeit 1200 lächerlicherweise als Groß bezeichnet).

Anmerkungen

Für die Breite 1920 ist beim Rendern keine Anpassung nötig. Für Höhe weiß ich nicht.

Vorschlagende Person

Thomas Ledl (Diskussion) 16:47, 31. Mai 2017 (CEST)

Diskussion

Es betrifft nicht nur das Herunterladen von Hintergrundbildern, sondern für mich vor allem die alltägliche Arbeit auf Commons, wo man Bildinhalte beurteilen möchte und ein ausreichend detailliertes Bildformat braucht, seinen Arbeitsspeicher aber nicht mit Megadateien belasten möchte, die den Browser schnell zum Absturz bringen. --Sitacuisses (Diskussion) 23:04, 8. Jun. 2017 (CEST)

• @Thomas Ledl: Das Hinzufügen weiterer Standardauflösungen wäre sicher sinnvoll (und kein großes Ding). Allerdings gebe ich zu bedenken, dass die Bilder auf Commons ganz unterschiedliche Bildproportionen haben, so dass man eigentlich immer nur die Breite ODER die Höhe festlegen kann und nicht beides gleichzeitig. Gerade Hochkant-Aufnahmen sollte man nicht einfach auf 1920*1080 croppen bzw. zerren.
  D.h. wenn es hier primär um Hintergrundbilder gehen sollte, müsste man die Funktionalität etwas aufwändiger gestalten oder eben auf die Bilder beschränken, die zumindest halbwegs die richtigen Proportionen haben. Außerdem sollte man diesen Fall mal lizenzrechtlich gegenchecken: Wenn man als Wikimedia nämlich das Bild allein, ohne Beschreibung vertreibt, dann könnte es durchaus nötig sein, eine entsprechende Urheber- und Lizenzangabe ins Bild zu packen. // Martin K. (Diskussion) 10:41, 16. Jun. 2017 (CEST)

Beispiel: https://upload.wikimedia.org/wikipedia/commons/thumb/9/94/Wien_Stubenring_18.jpg/829px-Wien_Stubenring_18.jpg

Skalierung in der Breite wird derzeit uneingeschränkt unterstützt. In der Ziel-URL findet sich dann z.b. /829px- oder /1024px-. D.h. bereits jetzt kann man hier einfach /1920px- eintragen und hat das in der Breite auf Wunschmaß skalierte Bild. Ob es dergleichen auch für die Höhe gibt weiß ich nicht, wäre aber sinnvoll. Wie das dann in die Oberfläche eingebunden wird überlasse ich den Webdesignern.

Was derzeit angeboten wird ist nicht mehr zeitgemäß. Eine Mediawiki-Anpassung ist daher gegenüber common.js vorzuziehen.

Die rechtliche Situation bleibt von diesen Änderungen unangetastet. --Thomas Ledl (Diskussion) 11:48, 16. Jun. 2017 (CEST)

Unterstützung

1.  Pro Thomas Ledl (Einreichende Person)
2.  Pro Jeb (Diskussion) 07:01, 20. Jun. 2017 (CEST)
3.  Pro --FNDE 11:45, 20. Jun. 2017 (CEST)
4.  Pro --Rettinghaus (Diskussion) 15:01, 20. Jun. 2017 (CEST)
5.  Pro -- Michi 19:52, 21. Jun. 2017 (CEST)
6.  Pro --Magnus (Diskussion) 16:02, 22. Jun. 2017 (CEST)
7.  Pro -- ÅñŧóñŜûŝî (Ð) 19:24, 22. Jun. 2017 (CEST)
8.  Pro -- Freddy2001 ^DISK 12:24, 24. Jun. 2017 (CEST)
9.  Pro Divof (Diskussion) 20:23, 24. Jun. 2017 (CEST)
10.  Pro --Merlin2001 (Diskussion) 12:48, 28. Jun. 2017 (CEST)
11.  Pro --Thomas Obermair 4 (Diskussion) 17:22, 28. Jun. 2017 (CEST)
12.  Pro --ProloSozz (Diskussion) 21:35, 2. Jul. 2017 (CEST) Zustimm, daß so ein Format nützlich wäre; aber auch weitere übliche Anzeigeformate wären nützlich; und 1024 in der Breite ist alles andere als obsolet; 1024x600 und v.a. 1024x768 sind nach wie vor sehr gängige Bildschirmauflösungen!
    
    

Rahmen für Bilder in Galerien ("Border"-Option)

Was ist das Problem?

Manche Bilder benötigen einen Rahmen, damit sie für den Betrachter besser unterscheidbar sind. Das betrifft z.B. häufig Flaggen oder Symbole mit sehr hellen oder weißen Flächen, die sich schlecht vom Hintergrund abheben.

Die Möglichkeit, einem Bild einen Rand oder Rahmen hinzuzufügen ("Border"-Option), besteht bei der Anzeige von Bildern als Thumb seit langem (durch Anfügen des optionalen Parameters "...|rand" bzw. "...|border").

In Galerien gibt es diese Möglichkeit aber nicht.

Wen betrifft das Problem besonders?

Benutzer und Leser, die Bilder in Galerien verwenden und anschauen.

Lösungsvorschlag

Die Möglichkeit, einem Bild auch bei der Anzeige in einer Galerie einen Rahmen hinzufügen zu können ("Border"-Option), könnte von einem Entwickler implementiert und anschließend auf den ensprechenden Hilfeseiten für die Anwender beschrieben werden.

Technisch kenne ich mich nicht aus, aber aus Anwendersicht würde ich mir wünschen, dass es vielleicht durch Anfügen des Parameters "...|rand" bzw. "...|border" an den Dateinamen des Bildes machbar sein könnte.

Anmerkungen

Ich versuche seit etwa drei Jahren, diesen Vorschlag mitzuteilen, bin aber bisher noch nicht bis zu jemandem vorgestoßen, der die Umsetzung tatsächlich veranlassen könnte.

Das Problem hatte ich daher schon öfters geschildert, zuerst hier: Hilfe Diskussion:Galerie#Hintergrundfarbe anpassbar?. Dort sind auch Beispiele abgebildet. Außerdem wurde der Wunsch 2015 und 2016 (2x) als Verbesserungsvorschlag eingereicht.

Ein anderer Benutzer, der sich mit den Kommunikationskanälen für solche technischen Verbesserungsvorschläge besser auskennt als ich, hat zwischenzeitlich versucht, die Anregung über das Gerrit-Portal an die Techniker zu melden: gerrit:312746. Dort wurde der Vorschlag aber bislang nicht zur Kenntnis genommen.

Von anderen Benutzern habe ich positive Reaktionen auf den Vorschlag bekommen, allgemeines Interesse scheint also durchaus zu bestehen, auch wenn es natürlich kein ganz extrem wichtiges Feature wäre.

Danke!

Vorschlagende Person

Jordi (Diskussion) 00:02, 2. Jun. 2017 (CEST)

Diskussion

Unterstützung

1.  Pro Jordi (Einreichende Person)
2.  Pro --Fährtenleser (Diskussion) 16:35, 20. Jun. 2017 (CEST)
3.  Pro --Jossi (Diskussion) 14:04, 22. Jun. 2017 (CEST)
4.  Pro --Merlin2001 (Diskussion) 12:49, 28. Jun. 2017 (CEST)
5.  Pro --Thomas Obermair 4 (Diskussion) 17:22, 28. Jun. 2017 (CEST)
6.  Pro --Sebastian Wallroth 13:58, 30. Jun. 2017 (CEST)
7.  Pro Der Umherirrende 16:49, 30. Jun. 2017 (CEST)
8.  Pro —DerHexer (Disk., Bew.) 23:33, 1. Jul. 2017 (CEST)
9.  Pro -- X:: black ::X (Diskussion) 21:27, 2. Jul. 2017 (CEST)
10.  Pro hätte ich schon mehrfach brauchen können Shaddim (Diskussion) 12:02, 9. Jul. 2017 (CEST)
    
    

Flexiblere Bildeinbindung als Ersatz für die Galeriefunktion

Was ist das Problem?

Die Einbindung von Einzelbildern und von Galerien ist bisher grundlegend unterschiedlich. Einzelbilder werden mit sehr schmalem Rand und eingerahmter Bildunterschrift eingebunden, die Bilder sind benutzerdefiniert skalierbar. Galerien haben einen sehr breiten Rahmen, der Bilder aller Seitenverhältnisse zum Quadrat macht, wodurch sehr viel Platz verbraucht wird. In der weit verbreiteten Standardeinstellung werden die Bilder sehr klein angezeigt, sie dienen so nicht der Artikelillustration, sondern sind nur bebilderte Links. Keine der Galerievarianten ist benutzerdefiniert skalierbar, auch alternativeb "experimentelle" Varianten nicht. Das Erscheinungsbild bleibt grundlegend anders als bei einzeln eingebundenen Bildern, was insbesondere dann unschön aussieht, wenn beide Einbindungsarten im Artikel sind. Zudem sind die "experimentellen" Varianten mit anderen Optionen zwangsweise gekoppelt, so sind sie z. B. nur zentriert einsetzbar. Weiterhin beanspruchen Galerien grundsätzlich die ganze Seitenbreite für sich, auch wenn sie den Platz nicht brauchen. Dies kann zu Layoutstörungen mit weißen Flächen führen, wenn rechts z. B. noch eine Infobox ist.

Galerien werden nicht nur am Artikelende eingesetzt; auch in längeren Artikeln ergibt sich mitunter die Notwendigkeit einer konzentrierten Darstellung von Bildern zu einem Teilaspekt, sodass die einfache Darstellung am rechten Rand nicht zweckmäßig ist.

Das Problem verschärft sich durch die immer weiter variierende Seitenbreite der Bildschirme. Man kann nicht alle Vorbedingungen für eine perfekte Darstellung vom Telefon bis zum 1920-Pixel-Bildschirm treffen, aber die Darstellung sollte wenigstens einigermaßen kompatibel sein. Das erfordert flexible Umbrüche.

Wen betrifft das Problem besonders?

Alle, denen an einem ansprechenden Erscheinungsbild bebilderter Artikel in variierenden Bildschirmbreiten gelegen ist.

Lösungsvorschlag

Ziel ist es, die Blöcke (Bild + Bildunterschrift + Rahmen drumherum), wie sie bei einer Einzeleinbindung bestehen, nicht nur am linken oder rechten Rand anordnen zu können, sondern mehrere Bilder (in Form dieser Blöcke!) in einer Zeile darzustellen und den Funktionen des Textumbruchs zu unterwerfen. Im Prinzip so ähnlich wie in der Textverarbeitung, wo man Bilder "mit Text in einer Zeile" anordnen kann, nur dass wir hier natürlich keinen Textfluss dabei haben. Dann können diese Blöcke auch Zeilenumbrüche auslösen, womit den Anforderungen extrem kleiner Bildschirme genüge getan wäre. Wenn man von der bisherigen Praxis von 3 oder 4 Bildern in einer Galerie ausgeht, würden die bei normalgroßem Bildschirm nebeneinander erscheinen (immer in Form der Einzeleinbindungsblöcke), würden sich Infoboxen am rechten Rand anpassen (d. h. ggf.vorzeitig umbrechen) und nur bei Bedarf in eine weitere Zeile rutschen. Die benutzerdefinierte Skalierung würde wirksam sein (ggf. modifiziert, siehe unten).

Die benutzerdefinierte Skalierung kann nur indirekt wirksam werden, weil sie auf die Seitenbreite wirkt. Hier ist aber eine absolut einheitliche Bildhöhe nötig. Es muss also umgerechnet werden. Bei Annahme eines Seitenverhältnisses von 3:2 (klassisches Kleinbildfilmseitenverhältnis) würde ich als Default den Faktor 0,667 vorschlagen, d. h. die Bildhöhe wird einheitlich auf 2/3 der vom Benutzer definierten Breite eingestellt, und das wird dann auf die ganze Galerie angewendet, auch wenn Bilder mit anderem Seitenverhältnis dabei sind. Dieser Verhältniswert muss als Parameter vom Artikelbearbeiter eingebbar sein, damit man z. B. auch Galerien aus Hochformaten angemessen darstellen kann. Eine wüst gemischte Darstellung von Quer- und Hochformaten sähe unschön aus, dafür wäre diese Galerie weniger geeignet.

Kompliziert wird es bei den Bildunterschriften. Für eine optimale Darstellung sollten die Bilder einer Zeile die gleiche Zeilenanzahl in der Bildunterschrift haben. Das ist nicht händisch zu steuern. Wünschenswert wäre eine automatische Anpassung aller Zeilanzahlen an den größten Platzbedarf.

Die vorgeschlagene Einbindung geht von linksbündiger Darstellung aus. Für die zentrierte Darstellung hat sich mir noch kein Grund erschlossen, wohl aber kann es in begrenztem Ausmaß sinnvoll sein, zumindest Bilderpaare auch rechts und mit Textfluss einzubinden. Bisher geht das nur mit behelfsmäßigen Funktionen, und das Ergebnis passt nicht exakt. Möglicherweise fällt diese Option automatisch mit ab; wenn nicht, sollte das ein eigenes (und nachrangiges) Thema sein.

Anmerkungen

Da die Funktionen zur Bildeinbindung unmittelbar in der Softwarefunktionalität enthalten sind, gehe ich davon aus, dass sie am besten auch dort verbessert werden. Möglicherweise wäre auch eine Lösung über eine Vorlage möglich, was dann außerhalb dieser Vorschläge stünde. Wenn jemand hierzu einen konkreten Ansatz hat (oder wenn es das z. B. in einer anderen Sprachversion auf Vorlagebasis schon gibt), bitte ich um Hinweis.

Die vorgeschlagene Funktion wäre geeignet, die "Briefmarken"- Galerie weitgehend abzulösen. Es mag einzelne Anwendungsfälle geben, in denen weiterhin die Galerie besser wäre, insbesondere stark variierende Seitenverhältnisse (sofern die nicht durch händische Umverteilung lösbar sind). Daher sollte nicht die vorhandene Galeriefunktion modifiziert werden, sondern die neue Darstellung zur wahlweisen Verwendung danebengestellt werden.

Vorschlagende Person

MBxd1 (Diskussion) 18:35, 4. Jun. 2017 (CEST)

Diskussion

• Galerien sind sehr wohl mit <gallery mode="packed" widths="100" heights="100"> skalierbar, oder meinst du was anderes? --Hannes 24 (Diskussion) 21:08, 7. Jun. 2017 (CEST)

Aber nur vom Bearbeiter, nicht vom Leser. Einzeln eingebundene Bilder folgen der Skalierung der Benutzereinstellungen (sofern da was drinsteht, sonst 220 Pixel als Breite), die Gallery kann das nicht. Es ist nicht ganz einzusehen, warum das so sein muss. MBxd1 (Diskussion) 21:16, 7. Jun. 2017 (CEST)

@MBxd1: Könntest du die Info aus deinem Kommentar noch bei „Was ist das Problem?“ ergänzen? Hintergrund: Bei der Abstimmung wird die Diskussion eingeklappt, damit klar ist, worüber abgestimmt wird (und damit wären dann deine Ergänzungen unsichtbar). -- Viele Grüße und besten Dank, Johanna Strodt (WMDE) (Diskussion) 19:20, 8. Jun. 2017 (CEST)

Erledigt. MBxd1 (Diskussion) 21:02, 8. Jun. 2017 (CEST)

Unterstützung

1.  Pro MBxd1 (Einreichende Person)
2.  Pro // Martin K. (Diskussion) 21:46, 20. Jun. 2017 (CEST) Für eine grundsätzliche Überarbeitung der Galeriefunktion
3.  Pro Jordi (Diskussion) 17:24, 21. Jun. 2017 (CEST) Sehe ich wie Martin K., wenn mögl. meinen Vorschlag einer "Border"-Option (Rahmen für Bilder auch in Galerien, s. o.) dabei mit berücksichtigen
4.  Pro--Jü (Diskussion) 06:33, 22. Jun. 2017 (CEST)
5.  Pro --Jossi (Diskussion) 14:05, 22. Jun. 2017 (CEST)
6.  Pro --TypeZero (Diskussion) 17:48, 22. Jun. 2017 (CEST)
7.  Pro --Geolina ^{mente et malleo} ✎ 20:57, 27. Jun. 2017 (CEST)
8.  Pro --Merlin2001 (Diskussion) 12:50, 28. Jun. 2017 (CEST)
9.  Pro --Ak ccm (Diskussion) 15:32, 28. Jun. 2017 (CEST) Sehe das genauso wie Martin K.
10.  Pro --Thomas Obermair 4 (Diskussion) 17:23, 28. Jun. 2017 (CEST)
11.  Pro —DerHexer (Disk., Bew.) 23:33, 1. Jul. 2017 (CEST)
    
    

WP:App Festlegen des Vorschaubildes

Was ist das Problem?

Das Vorschaubild in der WP-App ist eine wunderbare Hilfe, um dem Leser eine Orientierung zum gesuchten Artikel zu geben. Die App nutzt jedoch immer das erste Foto im Artikel, bei Ortartikeln ist dies in der Regel die Karte bei Denkmallisten entweder das erste Bild der Liste oder eine im Artikel befindliche Karte oder das Denkmallogo. Diese Bilder helfen dem Leser nicht, da Ortsfremde mit der Karte, die oft ein Aussschnitt aus einer Region ist, nichts anfangen können oder das erste Denkmal einer Liste nicht das aussagekräftigste ist (z. B. ein Kilometerstein statt einer Kirche oder eines Schlossees)

Wen betrifft das Problem besonders?

Nutzer der WP-App

Lösungsvorschlag

Artikelautoren sollen die Möglichkeit haben, ein abweichendes Teaserfoto im Artikel für die WP-App festzulegen. Wenn kein Foto festgelegt ist, soll automatisch das erste Foto gewählt werden.

Vorschlagende Person

 ^Thomas 08:25, 6. Jun. 2017 (CEST)

Diskussion

In Wikivoyage sind ansprechende Bilder oft der Aufhänger, einen Artikel durchzulesen, in den Ortsartikeln kann automatisch ein Kasten mit den Hauptinformationen aus in Wikidata hinterlegten Informationen generiert werden; in der Regel gibt es bei Wikidata ein Link auf ein einladendes oder aussagekräftiges Bild, vielleicht ein Weg zum Verfolgen, lg Martin - Mboesch (Diskussion) 21:47, 7. Jun. 2017 (CEST) Bild von Wikidata genau so wie der Untertitel? -- Freddy2001 ^DISK 12:24, 24. Jun. 2017 (CEST)

Unterstützung

1.  Pro Z thomas (Einreichende Person)
2.  Pro Jeb (Diskussion) 07:02, 20. Jun. 2017 (CEST)
3.  Pro --FNDE 11:47, 20. Jun. 2017 (CEST)
4.  Pro --HerrAdams (D) 18:54, 20. Jun. 2017 (CEST)
5.  Pro --Merlin2001 (Diskussion) 12:51, 28. Jun. 2017 (CEST) Analog natürlich für die Apps auf anderen Plattformen
6.  Pro --MoSchle Wichtig z.B. bei Ortsartikeln mit Infobox, bei denen jetzt nur eine Karte angezeigt wird.MoSchle (Diskussion) 13:02, 28. Jun. 2017 (CEST)
7.  Pro --Thomas Obermair 4 (Diskussion) 17:23, 28. Jun. 2017 (CEST)
8.  Pro --Morten Haan 🎲 Wikipedia ist für Leser da • Skin-Entwurf 01:07, 30. Jun. 2017 (CEST)
9.  Pro --Sebastian Wallroth 13:59, 30. Jun. 2017 (CEST)
10.  Pro -- Mboesch (Diskussion) 11:58, 1. Jul. 2017 (CEST)
11.  Pro --Fixuture (Diskussion) 23:21, 1. Jul. 2017 (CEST)
12.  Pro —DerHexer (Disk., Bew.) 23:34, 1. Jul. 2017 (CEST)
    
    

Suchen nach Dateien auf Commons, die überschrieben wurden

Was ist das Problem?

Commonsneulinge (oder beim Nutzen bestimmter Commons-App) laden versehentlich unterschiedliche Fotos mit demselben Titel hoch, so dass das erste überschriebene Fotos "quasi" verlorengehen. Dies passiert sehr oft bei Fotowettbewerben wie WLM und WLE. (Mehrfacher Upload der Kirche im Ort X mit dem Namen "Kirche in X.jpg"). Neulinge ignorieren die entsprechenden Warnungen und überladen so ihre eigenen Fotos.

Wen betrifft das Problem besonders?

Fotografen; Nutzer die Neulinge betreuen wollen

Lösungsvorschlag

Schaffung eines Tools mit dem nach überschriebene Fotos innerhalb einer Kat (mit Unterkats) oder eines Nutzers gesucht werden kann. Da das Überschreiben von Fotos vor allem nach der Bearbeitung von Bildern (Aufhellen, Beschneiden u. ä.) sinnvoll ist, darf das Überladen an sich nicht verhindert werden.

Anmerkungen

Das überschreiben von Fotos kann natürlich sinnvoll sein, wenn das Foto bearbeitet wurde.

Vorschlagende Person

 ^Thomas 08:51, 6. Jun. 2017 (CEST)

Diskussion

@Z thomas: Danke für diesen Wunsch! Eine Minianmerkung: Statt „überladen“ könntest du besser „überschrieben“ schreiben, das ist in dem Zusammenhang ein noch üblicherer Begriff. Und eine etwas größere Anmerkung zum Lösungsvorschlag: Du wünschst dir eine Suche nach überschriebenen Dateien, aber im Team fielen uns bei einer ersten Überlegung auch andere Möglichkeiten ein, das Problem anzugehen:

1. das Überschreiben vermeiden,
2. nach überschriebenen Bildern suchen können (dein Wunsch),
3. überschriebene Bilder einfacher unter einem neuen Namen hochladen können.

Bleibst du dabei, dass die Suche für dich besonders wichtig wäre? Dann wäre es schön, wenn du unter „Was ist das Problem?“ noch etwas darlegen könntest, warum. Falls du nicht dabei bleibst, solltest du den Wunschtitel und den Lösungsvorschlag entsprechend noch etwas umformulieren. -- Beste Grüße und vielen Dank, Johanna Strodt (WMDE) (Diskussion) 11:03, 15. Jun. 2017 (CEST)

@Johanna Strodt (WMDE): "überladen" hab ich angepasst, ich war mit dem begriff auch nciht so zufrieden :-) was meinst du mit "besonders wichtig"? es ist ein wunsch, den ich habe

danke für eure ideen.

zu 1. - nein, das überschreiben muss weiterhin möglich sein, z. B. wenn Dateien nachbearbeitet wurden

zu 2. ja

zu 3. ja, schön wäre es, wenn man das überschriebene Bild einfach mit der Maus rauziehen könnte :-) ich weiß aber nicht, ob das rechtliche dinge beachtet werden müssen. vielleicht weiß @32X: als commons-admin da mehr. -- ^Thomas 14:49, 15. Jun. 2017 (CEST)

@Z thomas: Was ich mit „besonders wichtig“ meinte: Du beschreibst ja ein Problem, zu dem es verschiedene Lösungen geben könnte. Nun könnte dein Wunsch sein, dass ganz allgemein das beschriebene Problem des Hochladens und Überschreibens beseitigt wird, egal mit welcher Lösung. Ebenso könnte es aber auch sein (und so ist es auch, oder?), dass dir gerade die Lösung über die Suche wichtig ist. Vielleicht liegt meine Rückfragerei daran, dass mir noch nicht so ganz klar ist, wie du die Suche genau einsetzen würdest. Kannst du dazu noch was schreiben, am besten bei „Was ist das Problem?“. Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 15:24, 15. Jun. 2017 (CEST)

@Johanna Strodt (WMDE): ah ok. ich dachte, dass meine Lösung das so formuliert hat, aber ich hab sie dahingehend präzisiert, dass es weiterhin notwendig sein muss, bilder zu überschreiben. ich hoffe, dass das so passt. viele Grüße -- ^Thomas 15:40, 15. Jun. 2017 (CEST)

@Z thomas: Merci! Alle Hinweise, inkl. der von 32X, sind mit Beginn der Abstimmung (19. Juni) nicht mehr sichtbar, also falls du noch was nach oben in den Wunsch „retten“ willst, mach das gerne. Ansonsten schon mal jetzt danke für deine Geduld! :) -- Liebe Grüße, Johanna Strodt (WMDE) (Diskussion) 16:47, 15. Jun. 2017 (CEST)

Da gibt es mehrere Fälle:

1. Unterschiedliches Foto, gleiche Person: In der Regel ist die Lizenz gleich.
2. Gleiches Foto, unterschiedliche Person: Meist ein bearbeitetes Foto, bei dem sich die Lizenz nicht ändert.
3. Unterschiedliches Foto (aber meist gleiches Motiv), unterschiedliche Person: Unter Umständen wurde eine andere Lizenz gewählt (manchmal aus dem Upload-Kommentar ersichtlich, der sich allerdings nicht in der Dateibeschreibung niederschlägt). Um an der Stelle sicher zu gehen, müsste der Nutzer angeschrieben werden.

Fall 3 wird man nicht automatisieren können (höchstens die Suche danach vereinfachen), Fall 2 ist hier uninteressant (wird aber bei der Suche auftauchen), Fall 1 ist der von Thomas beschriebene. Zu diesem noch einige Anmerkungen:

Bislang kann nur ein Administrator die Dateien trennen. Dazu wird alles regulär gelöscht, danach werden auf der Dateiwiederherstellungsseite fallabhängig der Upload und die dazugehörigen Versionen der Dateibeschreibung zur Wiederherstellung ausgewählt, die einen neuen Dateinamen erhalten sollen. Dann wird wiederhergestellt und (ohne Weiterleitung) verschoben. Diese Prozedur wird bei Bedarf so oft wiederholt, bis nur noch ein (unterschiedlicher) Upload vorhanden ist und dessen Versionen wiederhergestellt wurden. Hier ist in der Regel auch kein Verschieben mehr notwendig, es sei denn, der Name ist nichtssagend (Foto1234.jpg). Häufig kommt man nicht umhin, in allen Dateibeschreibungen anschließend noch Anpassungen vorzunehmen (z. B. ein anderes Aufnahmedatum). Manche Informationen muss man sich dazu auch im begrenzt langen Uploadkommentar heraussuchen. -- 32X 16:29, 15. Jun. 2017 (CEST)

Unterstützung

1.  Pro Z thomas (Einreichende Person)
2.  Pro --FNDE 11:47, 20. Jun. 2017 (CEST)
3.  Pro Conny 13:58, 21. Jun. 2017 (CEST).
4.  Pro --Thomas Obermair 4 (Diskussion) 17:23, 28. Jun. 2017 (CEST)
5.  Kontra Wenn jemand beim hochladen alle Meldungen ignoriert, ist ihm nicht zu helfen. Alte Versionen lassen sich auch wiederherstellen. --Snurb3010 (Diskussion) 22:30, 29. Jun. 2017 (CEST)

   Dazu muss man aber erst mal finden, welches Bild denn überschrieben wurde, bevor man da Versionen wiederherstellen kann. Dies ist ja der Wunsch. Außerdem geht es ja nicht nur um die Person, die das erste Bild überschreibt, sondern auch den Erstuploader. Wieso der durch ein Überschreiben des Bildes bestraft werden sollte, ist nicht klar. Der Person kann geholfen werden. —DerHexer (Disk., Bew.) 23:37, 1. Jul. 2017 (CEST)

6.  Pro --ProloSozz (Diskussion) 21:38, 2. Jul. 2017 (CEST) und dem Hexer pflichte ich bei ...
   
   

In Fließtext einbindbarer Audioplayer

Was ist das Problem?

Oft will man eine Audiodatei im Fließtext einbinden, zum Beispiel zur Erläuterung der Aussprache es Lemma (Bsp.: Subrahmanyan Chandrasekhar). Der derzeitige Audio-Player erlaubt dies nicht. Als Workaround, haben die Wikipedias Vorlagen gebastelt, die die Datei verlinken (hier: Vorlage:Audio). Das bedeutet aber auch dass man mit einem Klick auf den Link die Seite verlässt.

Wen betrifft das Problem besonders?

Insbesondere die Bereiche Biographien und Musik, aber auch alle anderen.

Lösungsvorschlag

Es sollte eine Version des Audio-Players geben, in der dieser idealerweise nur aus zwei Icons in Textgröße besteht, ein Audio-Icon und in Info-Icon (etwa: 🔊🛦). Ein Klick auf das Play-Icon spielt die Audiodatei ab ohne die Seite zu verlassen. Während der Wiedergabe wird das Play-Icon durch ein Stop-Icon – zum abbrechen der Wiedergabe – ersetzt (etwa: ⏹🛦). Ein klick auf das Info-Icon bringt einen auf die Dateibeschreibungsseite.

Vorschlagende Person

Michi 00:06, 10. Jun. 2017 (CEST)

Diskussion

Unterstützung

1.  Pro MichaelSchoenitzer (Einreichende Person)
2.  Pro  _hugarheimur 08:18, 20. Jun. 2017 (CEST)
3.  Pro --FNDE 11:48, 20. Jun. 2017 (CEST)
4.  Pro -- ^Thomas 13:52, 20. Jun. 2017 (CEST)
5.  Pro Jordi (Diskussion) 15:14, 20. Jun. 2017 (CEST)
6.  Pro Hermannh (Diskussion) 22:09, 20. Jun. 2017 (CEST)
7.  Pro … «« Man77 »» (A) wie Autor 10:10, 21. Jun. 2017 (CEST)
8.  Pro --Mushushu (Diskussion) 16:47, 25. Jun. 2017 (CEST)
9.  Pro --DianeAnna (Diskussion) 22:42, 25. Jun. 2017 (CEST)
10.  Pro --Merlin2001 (Diskussion) 12:52, 28. Jun. 2017 (CEST)
11.  Pro --Thomas Obermair 4 (Diskussion) 17:24, 28. Jun. 2017 (CEST)
12.  Pro --theredmonkey 11:21, 30. Jun. 2017 (CEST)
13.  Pro --Sebastian Wallroth 13:59, 30. Jun. 2017 (CEST)
14.  Pro -- Mboesch (Diskussion) 11:59, 1. Jul. 2017 (CEST)
15.  Pro --Fixuture (Diskussion) 23:24, 1. Jul. 2017 (CEST)
16.  Pro —DerHexer (Disk., Bew.) 23:38, 1. Jul. 2017 (CEST)
    
    

hochkant/upright-Parameter bei Bildern mit ungewöhnlichen Dimensionen (sehr hohe und schmale Bilder, Panoramabilder) automatisch mit sinnvollem Wert setzen

Was ist das Problem?

Bilder können mit dem hochkant/upright-Parameter skaliert werden, was insbesondere dann zum Einsatz kommen sollte, wenn das Bild ungewöhnliche Dimensionen hat und daher in der Standardbreite entweder zu groß oder zu klein wäre. Wir haben sogar einen Tipp des Tages für die Berechnung des Werts. Setzen muss man ihn trotzdem bislang immer von Hand. Da aber weder der Dialog im Wikitext-Editor noch der VisualEditor diesen Parameter kennt, ist das (im Falle des Wikitext-Editors) reine Handarbeit oder (im VisualEditor) unmöglich. Würde die Software anhand der Dimensionen des Bildes selbst erkennen, dass eine Skalierung angebracht ist und diese mit einem sinnvollen Wert durchführen, dann würde die Notwendigkeit, den Parameter manuell anzugeben, entfallen oder zumindest stark reduziert.

Wen betrifft das Problem besonders?

• Neue Benutzer, die sich nicht alle Bildparameter und ihre korrekte Verwendung merken wollen oder können, aber trotzdem Bilder in vernünftiger Größe in Artikel einfügen möchten
• Benutzer des VisualEditors

Lösungsvorschlag

Der letzte Versuch, die Skalierung automatisch durchzuführen, führte zu Kraut und Rüben, seitdem gab es keine sichtbare Entwicklung mehr in diesem Bereich, aber es sollte doch wohl möglich sein, die Skalierung automatisch durchzuführen, ohne dass Bilder mit „normalen“ Dimensionen betroffen sind, was damals zu der uneinheitlichen Breite führte.

Vorschlagende Person

Schnark 10:15, 10. Jun. 2017 (CEST)

Diskussion

Ich finde die Möglichkeit der manuellen Eingabe von Größenparametern, die natürlich auch für den VisualEditor geschaffen werden sollte, grundsätzlich angenehmer als eine Automatik, die im Einzelfall eine objektgerechte Darstellung verhindert.

Denkbar finde ich aber, "mini" ohne zusätzliche Eingaben statt für eine Standardbreite für eine Standardfläche stehen zu lassen, z. B. 30.000 Pixel im Kantenverhältnis der jeweiligen 100 %-Darstellung.

Stehen mehrere Bilder als Spalte untereinander, dann finde ich überdimensionierte Hochformate oder unterdimensionierte Querformate lästiger als unterschiedliche Breiten.--Ulamm (Kontakt) 11:11, 10. Jun. 2017 (CEST)

Letzteres halte ich für sehr problematisch. Das Problem ist das gleiche wie beim eigentlichen Vorschlag: Man möchte dem Erstbearbeiter eigentlich gern einen Default-Vorschlag mitgeben, den er (ggf. nur, weil er sich nicht auskennt) einfach übernimmt, den er aber auch bewusst abändern kann. Man kann ja nicht alle Hochformate hinsichtlich Zweck und Einbindung in einen Topf schmeißen. Wir können aber technisch nicht zwischen Erst- und Nachbearbeiter unterscheiden, das ginge nur dann, wenn man die Einbindung über eine einzufügende Vorlage realisieren würde, was auch nicht gewollt sein kann. Bei unterschiedlichen Querformaten würde ich unter keinen Umständen in die Skalierung eingreifen wollen, wie es Ulamm vorschlägt. Ich habe keine Statistik, wohl aber den Eindruck, dass sehr viele Fotos direkt von der Speicherkarte nach Commons kommen, ohne jemals ein Bildbearbeitungsprogramm gesehen zu haben. Kaum eine Kamera hält sich pixelgenau an die Seitenverhältnisse 3:2 und 4:3. Man hätte also immer wieder winzige Unterschiede in der Skalierung, die im Ergebnis fürchterlich aussehen. Hier einen Default drüberzubügeln, der bei den mittlerweile vermutlich Millionen von Querformatbildeinbindungen bei uns wieder händisch angepasst werden müsste, gäbe ein Desaster. MBxd1 (Diskussion) 11:34, 10. Jun. 2017 (CEST)

@Schnark: Hallo Schnark! Nur eine kurze Erinnerung, dass die Diskussion mit Beginn der Abstimmung (19. Juni) eingeklappt wird, damit klar ist, worüber abgestimmt wird. Falls hier in der Diskussion noch Informationen stecken, die für die Abstimmenden hilfreich sind, solltest du sie oben – z. B. unter „Was ist das Problem?“ oder „Lösungsvorschlag“ – noch im Laufe dieser Woche ergänzen. -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 10:33, 16. Jun. 2017 (CEST)

Unterstützung

1.  Pro Schnark (Einreichende Person)
2.  Pro --Jü (Diskussion) 06:36, 22. Jun. 2017 (CEST)
3.  Kontra Wenn ein Bild irgendwie überdimensioniert ist, wird es schon jemand manuell korrigieren. Problematisch wird es, wenn ein Bild tatsächlich größer sein soll, da es eine Totale ist o.Ä. --Wikiolo (D) 20:57, 27. Jun. 2017 (CEST)
4.  Pro --Merlin2001 (Diskussion) 12:53, 28. Jun. 2017 (CEST)
5.  Pro --Thomas Obermair 4 (Diskussion) 17:24, 28. Jun. 2017 (CEST)
6.  Pro --Snurb3010 (Diskussion) 22:32, 29. Jun. 2017 (CEST)
   
   

Unterstützung des MP3 Formats für Audiodateien

Was ist das Problem?

Audiodateien müssen in der Wikipedia/auf Commons im OGG oder OPUS Format hochgeladen werden. Meistens müssen Dateien hierfür konvertiert. Auch werden die Dateien nur als OGG im Artikel eingebunden, was dazu führt, dass diese z.B. auf dem iPhone nicht abgespielt werden können. Grund für den Verzicht auf MP3 sind die MP3-Patente, die nun aber abgelaufen sind

Wen betrifft das Problem besonders?

Leser auf iPhones oder iPads. Autoren, die Audiodateien hochladen, und dafür konvertieren müssen.

Lösungsvorschlag

Freischalten des MP3-Uploads auf Commons. Auslieferung von MP3-Dateien an iOS Geräte (und weitere Geräte, die kein OGG-Vorbis unterstützen).

(Möglicherweise muss die Konvertierung für MP3-Dateien gar nicht neu eingebaut werden, sondern ist momentan nur auf Grund der Patentproblematik deaktiviert und muss nur aktiviert werden.)

Vorschlagende Person

Ubahnverleih (Diskussion) 14:41, 11. Jun. 2017 (CEST)

Diskussion

Das ist bereits in Planung. Es hängt davon ab, was die Rechtsabteilung der WMF davon hält. Sagt sie Nein, wird es die Unterstützung auch weiterhin nicht geben; sagt sie JA, erfolgt die Unterstützung wahrscheinlich zügig. Siehe dazu in Phabricator: phab:T115170, phab:T120288 und phab:T162395. — Speravir – 00:39, 13. Jun. 2017 (CEST)

O, den Umkodierungsteil habe ich doch glatt übersehen. Das müsste dann wohl als neuer Phab-Task angefragt werden. — Speravir – 00:44, 13. Jun. 2017 (CEST)

Unterstützung

1.  Pro Ubahnverleih (Einreichende Person)
2.  Pro Martin K. (Diskussion) 10:02, 19. Jun. 2017 (CEST)
3.  Pro Jeb (Diskussion) 07:03, 20. Jun. 2017 (CEST)
4.  Pro --FNDE 11:50, 20. Jun. 2017 (CEST)
5.  Pro Jordi (Diskussion) 15:12, 20. Jun. 2017 (CEST)
6.  Pro --Blik (Diskussion) 17:03, 20. Jun. 2017 (CEST)
7.  Pro Gestumblindi 18:45, 20. Jun. 2017 (CEST) Wobei ich davon ausgehe, dass das spätestens 2018 sowieso kommen wird, nach Ablauf auch noch der allerletzten denkbaren Patente kann die Rechtsabteilung kaum etwas dagegen haben. Technisch ist es so trivial, MP3 zuzulassen, dass es sich hierbei m.E. nicht mal wirklich um einen "technischen Wunsch" handelt.
8.  Pro --  Sir Gawain Disk. 20:55, 20. Jun. 2017 (CEST)
9.  Pro -- Michi 19:52, 21. Jun. 2017 (CEST)
10.  Pro --Jossi (Diskussion) 14:06, 22. Jun. 2017 (CEST)
11.  Pro --Chiborg (Diskussion) 23:15, 23. Jun. 2017 (CEST)
12.  Pro --Merlin2001 (Diskussion) 12:54, 28. Jun. 2017 (CEST)
13.  Pro --Ak ccm (Diskussion) 15:21, 28. Jun. 2017 (CEST)
14.  Pro --Thomas Obermair 4 (Diskussion) 17:25, 28. Jun. 2017 (CEST)
15.  Pro -- Useibert~hawiktionary, 14:57, 29. Jun 2017 (CEST)
16.  Pro --Morten Haan 🎲 Wikipedia ist für Leser da • Skin-Entwurf 01:07, 30. Jun. 2017 (CEST)
17.  Pro —SDKmac (Disk., Bew.) 02:21, 30. Jun. 2017 (CEST)
18.  Pro --Sebastian Wallroth 14:00, 30. Jun. 2017 (CEST)
19.  Neutral --Boehm (Diskussion) 09:47, 2. Jul. 2017 (CEST) Das ist ein Problem, bei dem man sich an Apple wenden sollte, nicht an Wikipedia. Die Beschränkung der WP auf freie Formate ist richtig. Wenn mp3 frei ist, kann es auch berücksichtigt werden.

    @Boehm: Apple hat mit MP3 nichts zu tun und das Format ist je nach Betrachtung des Patentablaufs entweder schon kürzlich freigeworden oder wird es spätestens Ende Jahr sein. Gestumblindi 13:56, 2. Jul. 2017 (CEST)

    Wenn Apple freie Formate nicht unterstützt (OGG) und sogar aus Profitgründen das Abspielen von freien Formaten verhindert um eigene proprietäre Formate durchzudrücken, dann sollte das WP nicht unterstützen. Wenn ein Apple-User die freie WP nicht vollständig nutzen kann, dann soll er sich an Apple wenden und das von denen verlangen oder den Anbieter wechseln. Ein Wechseln von Wikipedia auf unfreie Formate ist hier nicht die Lösung. Sobald mp3 frei ist kann es verwendet werden. --Boehm (Diskussion) 14:25, 2. Jul. 2017 (CEST)
    
    

Einbindung interaktiver Medieninhalte ermöglichen

Was ist das Problem?

Aktuell können in der Wikipedia nur statische Bilder oder lineare Video-Dateien zur Visualisierung von Inhalten verwendet werden. Interaktive Diagramme, -Infografiken oder -Animationen sind nicht möglich oder müssen mit Wikitext zusammengefriemelt werden bzw. (wie beim OSM-Atlas) als Einzel-Features integriert werden.

Es würde die Attraktivität unserer Enzyklopädie erheblich steigern, wenn wir genauso wie viele andere Medien einfacher auch interaktive Inhalte einbinden könnten. Der Wunsch beinhaltet insbesondere:

• Interaktive SVGs (die Sachverhalte deutlich begreiflicher machen können als statische).

Wenn machbar, sollte jedoch eine generale Lösung bereitgestellt werden, auf deren Basis perspektivisch weitere interaktive Inhalte wie die Folgenden eingebunden werden könnten (Spezifizierung aus der Diskussion ergänzt von --Birgit Müller (WMDE) (Diskussion) 09:31, 19. Jun. 2017 (CEST)).

Weitere Beispiele:

• 360°-Kugelpanoramen (die heute per Link in einem externen Player geöffnet werden)
• Interaktive Diagramme und Graphen (in denen z.B. bestimmte Werte hin- und weggefiltert oder Zeiträume variiert werden könne.
• Vorher/nachher Bilder mit Schieberegler
• Mit Markern oder Overlays versehene Bilder und Karten
• Interaktiv verlinkte Videos oder 360°-Videos

Dank HTML5/CSS3/JavaScript sind solche Inhalte standardkonform und ggf. sogar barrierearm realisierbar - auch von ambitionierten Laien.

Wen betrifft das Problem besonders?

Alle Leser der Wikipedia

Lösungsvorschlag

Voraussetzung für die Verwendung solcher Inhalte in der Wikipedia ist eine Möglichkeit zur Einbettung in den Artikeln. Statt hier in Ausnahmefällenwieder Einzellösungen zusammenzubasteln, wäre es sinnvoll einmal eine generelle Einbettungslösung zu entwickeln, in die dann verschiedene, ggf. noch zu entwickelnde Medientypen eingebettet werden können. Meiner Einschätzung nach würde sich hier technisch eine Iframe-Lösung anbieten, die weitestgehend inhaltsagnostisch ist und deren Code der Inhalte so kapselbar macht, dass keine XSS-Probleme verhindern kann.

Es wäre sinnvoll, hier zwei Einbettungoptionen anzudenken:

• Ein (statisches) Thumb öffnet die interaktive Ansicht im Mediaplayer
• Es wird direkt eine interaktive Ansicht (mit definierbarer Proportionen und Größe) in den Artikel eingebunden.

Als Inhalte wären bereits heute diverse interaktive SVGs verfügbar (die natürlich nur dann funktionieren, wenn das SVG selbst angezeigt wird) und auch der Wikimedia-Panorama-Viewer könnte so eingebunden werden. Für den ersten Ausbauschritt würden sich zudem die Vorher-/Nachherbilder anbieten, für die es sicher auch einige Einsatzzwecke gibt.

Anmerkungen

Natürlich sollten auf diese Weise nur Inhalte eingebunden werden, die auf Wikimedia-Server gehostet und dort entsprechend sicherheitstechnisch überprüft wurden. Bei den SVGs auf Commons ist das bereits heute der Fall. Und auch der Panorama-Player auf WMFLabs dürfte in dieser Hinsicht unkritisch sein. Sobald die Grundvoraussetzungen der Einbindung in Frontend und MediaViewer geschaffen sind, kann man sukzessiv Hosting, Review und Freigabe entsprechender Medientypen besprechen und für die Wiki-Einbindung entsprechende Container-Vorlagen schaffen.

Vorschlagende Person

Martin K. (Diskussion) 17:35, 11. Jun. 2017 (CEST)

Diskussion

Hallo Martin K., Danke für deinen Wunsch! Könntest du ihn bitte auf ein Medien-Format eingrenzen, das dir besonders wichtig ist? Andernfalls ist der Wunsch leider nicht umsetzbar, weil er den Rahmen der „Technische Wünsche“ bei weitem sprengt. Zu Kugelpanoramen gibt es übrigens auch schon einen anderen Wunsch: Wikipedia:Umfragen/Technische_Wünsche_2017/Schwesterprojekte#Darstellung_von_sphärischen_Panoramas_in_Wikipedia. Du könntest also diesen Wunsch hier auf ein anderes Format eingrenzen. Ansonsten würden wir die Einreichung in die Rubrik „Wünsche außerhalb des Projektrahmens“ verschieben. Eingrenzung bis Sonntagnachmittag wäre super, weil die Umfrage am Montag losgeht & wir das ggf. auch noch verschieben müssten. -- Liebe Grüße, --Birgit Müller (WMDE) (Diskussion) 18:51, 16. Jun. 2017 (CEST)

@Birgit Müller (WMDE): Mir geht es ausdrücklich nicht nur um ein einzelnes zusätzliches Medienformat, sondern um einen Container für beliebige Webstandard-konforme Inhalte. Klar, dass wir den aus Sicherheitsgründen nicht mit beliebigen URLs füttern sollten. Aber man könnte ihn auf bestimmte Wikimedia-URLs (z.B. die Commons-SVGs, z.B. der Panoplayer) locken, auf denen man dann nach weitere Inhalte/Inhaltsarten anbieten kann.

Wieso sollte das nicht in den Projektrahmen fallen? // Martin K. (Diskussion) 19:25, 16. Jun. 2017 (CEST)

Hallo Martin K., sorry für die späte Antwort, irgendwie ist mir deine Antwort durchgerutscht :-( - Das Sicherheitsrisiko besteht insbesondere darin, den Upload beliebiger Inhalte bzw Formate zuzulassen, und diese von Wikimedia aus zugänglich zu machen. Es können jedoch nur sichere Inhalte auf den Wikimedia-Servern sein. Der Wunsch nach "beliebigen Formaten" könnte das Team nur pauschal ablehnen, das bekommt man nicht sicher. es könnte für Filesharing missbraucht werden, wir können nicht sicherstellen, dass die Inhalte für Benutzer mit anderen Betriebssystemen etc. überhaupt angezeigt werden können, etc. Sinnvoll wäre es, über bessere Unterstützung konkreter einzelner Formate zu sprechen und dementsprechend den Wunsch auf ein Format einzugrenzen. Wenn du dich nicht auf konkrete Formate beschränken möchtest, müssten Communities, WMF ... zunächst Kriterien für Formate festlegen, die unterstützt werden können oder sollen, das wäre in der Form auch nicht wirklich was für die Wunschliste. Hilft das erstmal weiter? Eingrenzung auf ein Format wäre noch bis morgen früh um 9 möglich ... (Sorry, ich glaube besser bekomme ich das jetzt nicht mehr formuliert, aber wir haben diesen Wunsch im Team kurz besprochen und alle sagen: geht in dieser Form aus unterschiedlichen Gründen nicht, davon die meisten hier genannt ;) - Viele Grüße, --Birgit Müller (WMDE) (Diskussion) 22:58, 18. Jun. 2017 (CEST)

@Birgit Müller (WMDE): Mir ist schon klar, dass wir hier nicht einfach jeden beliebige Inhalte einbinden lassen sollte - das schlage ich ja auch gar nicht vor. Ich denke wir sollen hier zwei Dinge unterscheiden:

1. Die Schaffung der technischen Voraussetzung um gekapselt in einem iFrames HTML/CSS/SVG/JS Inhalte ins Wiki einzubinden.
2. Das Hosting und die Kuratierung (code review) eben dieser Inhalte.

In meinem Wunsch geht es zunächst mal um 1. Das ist nämlich die Voraussetzung dafür, dass man die in 2. benötigten medienspezifischen Prozesse überhaupt entwickeln kann.

Natürlich steht es außer Frage, dass dort nicht einfach irgendwelche URLs aus den Weiten des Webs eingebunden werden sollten, sondern (genauso wie bei den Bildern auch) ausschließlich Inhalte von Wikimedia-Server. Und die Implementierung muss natürlich sicherstellen, dass nur Ressourcen von solchen verifizierten Wikimedia-Sourcen akzeptiert werden. In einem ersten Schritt geht es mir um...

• die interaktiven SVGs, die heute schon Commons gehostet werden und die dortigen Sicherheitschecks durchlaufen haben.
• den aktuell auf WMFLabs gehostet Panoramaplayer
• eine vergleichbare Anwendung für Vorher-/Nachherbilder (könnte ich gerne entwickeln, ist ja kein Hexenwerk)

Wie bereits geschrieben, macht es aber keinen Sinn für jeden dieser Fälle jeweils eine Insellösung zu stricken, wenn es so einfach wäre eine gemeinsame Grundlage zu schaffen, die zukünftig auch für weitere Inhalte genutzt werden kann. Für jeden weiteren Medientyp müsste man auf Anzeige-Seite dann nur noch eine neue Resource zulassen und eine Container-Vorlage für die einbinden Autoren bauen.

Ich hoffe das macht die Sache klarer?! // Martin K. (Diskussion) 23:32, 18. Jun. 2017 (CEST)

Hi Martin! JavaScript ist an sich schon problematisch genug. Die Idee hinter der Same-Origin-Policy, die JavaScript halbwegs sicher macht, ist ja, dass man sich JS zueigen macht, wenn man es von seiner Domain ausliefert - und dass man einverstanden ist, dass solches JavaScript zugriff hat auf den "Kontext" der domain, insbesondere auch auf die Session. Wir würden hier beliebigen Benutzern erlauben, beliebiges JavaScript auf den Wikimedia-Servern zu parken, dass dann von unserer Domain aus an andere Benutzer ausgeliefert würde. Das ist besorgniserregend, wenn auch nicht unbedingt unsicher.

Mediendateien werden ja glücklicherweise von upload.wikimedia.org ausgeliefert, und an diese Domain schicken wir (hoffentlich?!) nie Session-Cookies. Wenn doch, hätten wir da ein großes Loch. IFrames helfen hier nur bedingt, das entscheidende ist die Domain, von der Geladen wird.

IFrames sind aber im allgemeinen unbeliebt, und gelten in HTML 5 als "deprecated". Aber ganz ausgeschieden ist die Idee nicht, siehe < https://phabricator.wikimedia.org/T131436 >. Vielleicht lohnt es sich, darüber mal mit der Foundation zu reden.

Was andere Formate angeht - jedes Einzelne muss unter Sicherheitsgesichtspunkten analysiert werden, und ggf muss ein Upload-Filter geschrieben werden. Jedes einzelne braucht ggf einen anderen "Player", zumindest als Fallback für Browser, die das Format nicht nativ unterstützen. Für die Druckansicht braucht es statisches Rendering, für Geräte mit kleinem Bildschirm und/oder geringer Bandbreite braucht es Thumbnails... Aber mir ist ohnehin unklar, über was für Formate wir sprechen... welche Kandidaten für interaktive Inhalte mit nativem Support im Browsern gibt es denn noch? -- Daniel Kinzler (WMDE) (Diskussion) 19:50, 19. Jun. 2017 (CEST)

@Daniel Kinzler (WMDE): Ich hatte doch oben schon geschrieben, dass ich eben NICHT vorschlage, dass hier jeder irgendwas hochladen kann, dass dann einfach blind eingebunden wird?! Es ist selbstverständlich, dass man sich bei der Implementierung dieses Wunsches einige Gedanken darüber machen muss, wie man diese Inhalte bestmöglich sandboxed. Und dazu gehört natürlich auch, dass man sie eben von einer Domain lädt, die nicht im selben SOP-Scope liegt wie der Rest der WP. Die oben angesprochenen SVGs z.B. werden ja heute schon über upload.wikimedia.org ausgeliefert. Bei Medieninhalten ist es ja weder notwendig noch wünschenswert, dass ihr CSS/JS mit dem Rest des Wikis interferiert.

Oben wurden ja drei konkrete Medienarten genannt, die heute schon verfügbar (bzw. einfach zu entwickeln) sind und aus Sicherheitssicht eher unkritisch sein dürften, weil sie entweder eh schon über Wikimedia-Server ausgeliefert werden (SVG) oder einen detailierten Code-Review unterzogen werden können (PanoramaPlayer, VorherNachherPlayer). Es sind natürlich perspektivisch etliche weitere Anwendungen für diesen Mediencontainer denkbar. Aber über die kann man sich (a) dann den Kopf zerbrechen, wenn sie anstehen und (b) würde die dann nötige Detailierte Ausarbeitung von deren Implementierung die hiesige Umfrage überfordern.

Also: Lasst uns bitte nicht den dritten Schritt vor dem ersten machen, sondern erstmal die Voraussetzungen schaffen (Front-End-Container) und diese dann an den drei genannten UseCases ausprobieren. Danach sehen wir weiter...

P.S.: Wo hast Du die Information her, dass iframes in HTML5 deprecated seien? Beim W3C finde ich nichts dergleichen? Meines Wissens wurden mit HTML5 normale Frames und Framesets als veraltet gekennzeichnet, nicht aber iFrames. Gerade angesichts von deren ubiquitären Anwendung im Werbe- und Video-Bereich (mit dem Ziel Fremdinhalte zu sandboxen) wäre das auch ziemlich widersinnig, oder?!

P.P.S.: Das Sandboxing von iFrames lässt sich übrigens steuern. // Martin K. (Diskussion) 21:14, 19. Jun. 2017 (CEST)

P.P.P.S.: Interaktive Inhalte sind für mich übrigens eine Progressive Verbesserung, in die man nicht die für das Verständnis des Artikels kriegsentscheidenden Inhalte packen sollte. Und natürlich muss man sich bei deren Entwicklung (wie bei jeder heutigen Webanwendung) Gedanken darüber machen, was passieren soll, wenn etwas schief geht.

• Im profansten Fall würde dann einfach das oben schon angedachte statische Vorschaubild mit einer entsprechenden Meldung angezeigt. Bei den SVGs, wäre das das normale Thumb und beim Panoplayer und den Vorher-nachher-Bildern das oder die jeweilige Ausgangsfotos.
• Und wenn wir (in Ausbaustufe zwei) von Diagrammen, Karten oder Konfigurationen reden, kann man dort (genauso wie bei anderen Webanwendungen) auch eine barrierearme Fallbackversion implementieren.

P.P.P.P.S.: Mir fällt übrigens mindestens ein halbes Dutzend weiterer UseCases für diesen Interaktive-Inhalte-Container ein (von Interaktiven Karten zur Verortung irgendwelcher Inhalte, über digitale Experimente bei technischen Themen bis hin zu steuerbaren Graphen und Diagrammen). Hier gäbe es massig Möglichkeiten unser Projekt besser und interessanter zu machen. Aber so lange es nicht mal absehbar ist, dass man so was in die WP einbinden könnte, wird sich kein Freiwilliger hinsetzen und irgendwas für die Tonne entwickeln. Ziel dieses Wunsches ist es, genau das zu ändern. // Martin K. (Diskussion) 21:30, 19. Jun. 2017 (CEST)

Für 3D-Modelle gibt's schon was in der Art: [1] - soll dann wohl demnächst ausgeliefert werden: phab:T3790, Commons VP. --El Grafo _(COM) 09:23, 23. Jun. 2017 (CEST)

Unterstützung

1.  Pro --Martin Kraft (Einreichende Person)
2.  Pro --FNDE 11:51, 20. Jun. 2017 (CEST)
3.  Pro --Noobius2 (Diskussion) 16:24, 20. Jun. 2017 (CEST)
4.  Pro --Michi 19:52, 21. Jun. 2017 (CEST)
5.  Pro --El Grafo _(COM) 09:23, 23. Jun. 2017 (CEST)
6.  Pro --2DragonFreak (Diskussion) 18:28, 27. Jun. 2017 (CEST)
7.  Pro --Thomas Obermair 4 (Diskussion) 17:25, 28. Jun. 2017 (CEST)
8.  Pro --Snurb3010 (Diskussion) 22:34, 29. Jun. 2017 (CEST)
9.  Pro --Morten Haan 🎲 Wikipedia ist für Leser da • Skin-Entwurf 01:07, 30. Jun. 2017 (CEST)
10.  Pro --theredmonkey 11:15, 30. Jun. 2017 (CEST)
11.  Pro --Sebastian Wallroth 14:01, 30. Jun. 2017 (CEST)
12.  Pro --DerHexer (Disk., Bew.) 23:39, 1. Jul. 2017 (CEST)
13.  Pro --Merlin2001 (Diskussion) 20:20, 2. Jul. 2017 (CEST)
14.  Pro -- Mr N (Diskussion) 23:53, 2. Jul. 2017 (CEST) Oh ja. Bitte.
15. Abwartend Prinzipiell eine interessante Idee, aber ich sehe sehr viele drängendere Probleme, deren Lösung (derzeit noch) weit weniger aufwändig ist. -- X:: black ::X (Diskussion) 23:57, 2. Jul. 2017 (CEST)
    
    

Platzsparende Galerie für Bilder ermöglichen

Was ist das Problem?

Für Galerien von Bildern gibt es verschiedene Modi. Der nolines-mode wirkt bei unterschiedlichformatigen Bildern etwas unstrukturiert, andere Modi hingegen verbrauchen (zumindestens dann, wenn auch breitformatige Bilder verwendet werden) relativ viel Platz. Daher bin ich dafür, einen weiteren, strukturierten und zugleich platzsparenden Modus zu entwickeln und bereitzustellen.

Wen betrifft das Problem besonders?

Nutzer und Autoren von Artikeln mit Galerien aus Bildern

Lösungsvorschlag

Der zusätzliche Modus könnte folgennden Effekt haben:
Bei dem Bild mit der größten Höhe wird auf den Innenabstand zwischen Bild und Rahmen verzichtet und der Rahmen unmittelbar an das Bild angelegt. Alle anderen Rahmen würden sich mit ihrer oberen und unteren Rahmenlinie an der oberen und unteren Rahmenlinie des Bildes mit der größten Höhe orientieren, ihre rechte und linke Rahmenlinie jedoch würden sich ebenfalls unmittelbar an ihr jeweiliges Bild anlegen. Zudem wäre es gut, wenn optional eine vertikale Zentrierung letzterer Bilder im so definierten Rahmen einstellbar wäre (wie sie auch im Standardmodus erfolgt). Außerdem halte ich es für wünschenswert, optional auch einen weiteren äußeren Rahmen um die gesamte Gallerie samt Bildunterschriften etc. anzeigen zu können. Ebenso eine Option, die Schriftgröße der Bildunterschriften etwas zu verkleinern, auf die bei Dateieinbindungen übliche Standgröße.

Vorschlagende Person

X:: black ::X (Diskussion) 23:13, 11. Jun. 2017 (CEST)

Diskussion

Unterstützung

1.  Pro X:: black ::X (Einreichende Person)
2.  Pro -- SuPich [Diskussion] [Beiträge] um 14:37, 26. Jun. 2017 (CEST)
3.  Pro --Thomas Obermair 4 (Diskussion) 17:25, 28. Jun. 2017 (CEST)
4.  Pro --Snurb3010 (Diskussion) 22:36, 29. Jun. 2017 (CEST)
   
   

Lizenzhinweise beim Speichern von Bildern anzeigen

Was ist das Problem?

Es gibt leider regelmäßig Probleme mit Urheberrechtsverletzungen durch die nicht lizenzkonforme Nachnutzung von Fotos und den daraus resultierenden Abmahnungen. Häufig rechtfertigen das die Nachnutzer damit, sie hätten ja nicht gewusst, dass Sie Namen und Lizenz angeben müssten. Was auch daran liegen könnte, dass viele nicht bis zu den Bilddetailseiten mit den Lizenzhinweisen vordringen.

Wen betrifft das Problem besonders?

• die Nutzer von in der Wikipedia publizierten Bildern
• die Urheber dieser Bilder

Lösungsvorschlag

Wer ein Bild nachnutzen will, muss es zunächst speichern. Dies geschieht i.d.R. durch einen Rechtsklick auf das Bild oder per Drag'n'Drop. Diese Ereignisse sollte man auf allen Bildern per JavaScript abfangen, um dann passende Hinweise auf die Lizenzbedingungen und z.B. einen Link auf den Lizenzhinweisgenerator anzuzeigen.

Dies könnte helfen die Lizenzverletzungen und die daraus resuktierenden Abmahnprobleme zu reduzieren.

Vorschlagende Person

Martin K. (Diskussion) 23:14, 11. Jun. 2017 (CEST)

Diskussion

Soll man das bei jedem Speichern bestätigen müssen? Klingt ziemlich nervig. —DerHexer (Disk., Bew.) 23:41, 1. Jul. 2017 (CEST)

Unterstützung

1.  Pro Martin Kraft (Einreichende Person)
2.  Pro --Smial (Diskussion) 17:24, 20. Jun. 2017 (CEST)
3.  Pro --Methodios (Diskussion) 19:22, 20. Jun. 2017 (CEST)
4.  Pro --Alchemist-hp (Diskussion) 20:39, 20. Jun. 2017 (CEST)
5.  Pro --Till.niermann (Diskussion) 20:59, 20. Jun. 2017 (CEST)
6.  Pro --Alturand (Diskussion) 21:25, 21. Jun. 2017 (CEST) Sicher nicht rechtssicher ggü. böswilligen Nachnutzern, aber es dürfte helfen, die "Unfälle" zu verhindern und die wenige Spreu vom vielen Weizen zu trennen.
7.  Pro --TypeZero (Diskussion) 17:49, 22. Jun. 2017 (CEST)
8.  Pro -- Freddy2001 ^DISK 12:25, 24. Jun. 2017 (CEST)
9.  Pro --Geolina ^{mente et malleo} ✎ 20:59, 27. Jun. 2017 (CEST) (als ein Baustein in dem Gesamtkomplex)
10.  Pro --Ak ccm (Diskussion) 15:24, 28. Jun. 2017 (CEST)
11.  Pro --Thomas Obermair 4 (Diskussion) 17:26, 28. Jun. 2017 (CEST)
12.  Pro -- Useibert~hawiktionary, 14:58, 29. Jun 2017 (CEST)
13.  Kontra Funktioniert nur solange man sich das Bild in HTML eingebettet anschaut. --Snurb3010 (Diskussion) 22:49, 29. Jun. 2017 (CEST)
14.  Pro --Sebastian Wallroth 14:02, 30. Jun. 2017 (CEST)
15.  Pro -- Mboesch (Diskussion) 12:00, 1. Jul. 2017 (CEST)
16.  Kontra --ProloSozz (Diskussion) 23:01, 2. Jul. 2017 (CEST) a) unwirksam, wenn kein JS genutzt wird (was viele tun); oder b) Bild könnte gar nicht mehr gespeichert werden (nicht mal für Privatgebrauch oder zum Betrachten von Details); Alternative: Bild muß von einer Seite gespeichert werden, wo die Urheber- und Nutzungsrechtshinweise als normalen Inhalt eingebunden sind; d.h. UHR-Hinweise nicht unten unter dem Bild, sondern oben oberhalb des Bildes einbinden. Jedesmal UHR-Bestätigungsbutton o.ä. setzen müssen ist Kindergartengängelei.
    
    

Hochkant-Funktion als Standardoption für die Funktion eingebettete Datei im Quelltext-Editor

Was ist das Problem?

Der Quelltext-Editor enthält bereits eine gewisse Auswahl von Standardparametern für die Einbindung von Bilddateien (5. Icon in der Toolbar) – bisher allerdings nicht die (nicht selten genutzte) Option hochkant. Diese könnte man in der Rubrik Format aufführen; dort finden sich ja bereits mehrere andere Optionen (miniatur, gerahmt, rahmenlos, keine). Ich denke, dies wäre für sämtliche WM-Projekte eine sinnvolle Ergänzung.

Wen betrifft das Problem besonders?

Autoren

Vorschlagende Person

Curc (Diskussion) 23:43, 11. Jun. 2017 (CEST)

Diskussion

@Curc: So ganz verstehe ich denn Sinn dieses Wunsches nicht? Wieso sollten denn jetzt alle Bilder standardmäßig hochkant sein? // Martin K. (Diskussion) 12:54, 26. Jun. 2017 (CEST)

@Martin Kraft: Danke, aber so war das ja nicht gemeint. Ich wollte damit lediglich sagen, dass die Option hochkant als eine von mehreren standardmäßig in der Rubrik Format aufgeführt sein soll; dort finden sich ja bereits mehrere andere Optionen (miniatur, gerahmt, rahmenlos, keine). So verständlicher?--Curc (Diskussion) 18:25, 26. Jun. 2017 (CEST)

PS: Wofür soll hier eigentlich keine genau stehen?--Curc (Diskussion) 18:28, 26. Jun. 2017 (CEST)

@Curc: Ah, ich vestehe: Du meist also die Felder, in dem Diaogfeld, das man über den Button oben öffnet?! Das hab ich ehrlich gesagt noch nie benutzt.

Ich würde Dir empfehlen dass oben etwas besser zu erläutern. Aktuell versteht man es nämlich nicht. // Martin K. (Diskussion) 19:17, 26. Jun. 2017 (CEST)

Erledigt, danke!--Curc (Diskussion) 19:20, 26. Jun. 2017 (CEST)

Unterstützung

1.  Pro Curc (Einreichende Person)
2.  Pro Jordi (Diskussion) 15:08, 20. Jun. 2017 (CEST)
3.  Kontra --Geolina ^{mente et malleo} ✎ 21:02, 27. Jun. 2017 (CEST)
4.  Pro --Merlin2001 (Diskussion) 12:57, 28. Jun. 2017 (CEST) Würde sogar eventuell durch die automatische Vergabe des Parameters (siehe Idee oben) unnötig werden
5.  Pro --Thomas Obermair 4 (Diskussion) 17:26, 28. Jun. 2017 (CEST)
6.  Pro -- X:: black ::X (Diskussion) 21:47, 2. Jul. 2017 (CEST)
   
   

Kompatibilität von Medienbetrachter und Commons verbessern

Was ist das Problem?

Wenn man in WP ein Bild anklickt und dann durch nochmaliges Klicken zur Commons-Datei gelangt, finden einige Browser, insb. Firefox, beim Zurückklicken in den Artikel nicht mehr die richtige Position, an der sich das angeklickte Bild befindet – man landet stets wieder am Anfang des Artikels, was recht nervig sein kann. Daher würde ich vorschlagen, für alle WM-Projekte eine verbesserte, browserunabhängige Kompatibilität zwischen Medienbetrachter und Commons herzustellen.

Wen betrifft das Problem besonders?

Vorschlagende Person

Curc (Diskussion) 23:57, 11. Jun. 2017 (CEST)

Diskussion

Unterstützung

1.  Pro Curc (Einreichende Person)
2.  Pro --FNDE 11:52, 20. Jun. 2017 (CEST)
3.  Pro Gleiches betrifft den "neuen" WYSIWYG Editor, wenn ich mich nicht irre. Divof (Diskussion) 20:25, 24. Jun. 2017 (CEST)
4.  Pro --Thomas Obermair 4 (Diskussion) 17:26, 28. Jun. 2017 (CEST)
5.  Pro --Morten Haan 🎲 Wikipedia ist für Leser da • Skin-Entwurf 01:07, 30. Jun. 2017 (CEST)
6.  Pro Eigentlich Nr. 7, aber aus mir unbekanntem Grund bleiben in diesem Abschitt Quelltexteintragungen hinter der Nachfolgenden Unterschrift unsichtbar (nicht dargestellt) (@ all und C21H22N2O2). -- X:: black ::X (Diskussion) 22:09, 2. Jul. 2017 (CEST)
7.  Pro --C₂₁H₂₂N₂O₂ (Diskussion) 22:17, 2. Jul. 2017 (CEST)
   
   

Thumbnailgrößen responsiv setzen

Was ist das Problem?

Das manuelle Setzen der Größen vorn Vorschaubildern sorgt immer wieder für Meinungsverschiedenheiten. Jeder designt für seine Monitorauflösungen und letztlich wird das Ergebnis einem Großteil der Plattformen nicht gerecht.

Einerseits verdrängen zu große Bilder auf kleinen Endgeräten viel zu viel Text. Oder die Mini-Thumbnails verlieren sich auf einem >FullHD-Monitor auf dem eigentlich massenhaft Platz zur Verfügung stände. Das diese winzigen Ansichten im Zeitalter Responsiven Webdesigns nicht mehr zeitgemäß ist, sieht man ja an den alternativen Wikimedia-Renderen die (genau wie die meisten aktuellen Website) auflösungsabhängig wesentlich großzügiger mit den Bildgrößen umgehen.

Wen betrifft das Problem besonders?

Alle Leser.

Lösungsvorschlag

Die Bildgrößen sollten nicht mehr von den Autoren hart auf Pixel gesetzt werden. Stattdessen sollte man sie nur noch semantisch auszeichnen und die tatsächlichen Darstellungsgrößen und ggf. auch das zusammenfassen zu Kategorien automatisch zu berechnen. Dies sollte dazuführen, dass jeweils die Bildgröße und Anordnung angezeigt wird, die für das jeweilige Endgerät und die jeweilige Auflösung passt.

Vorschlagende Person

Martin K. (Diskussion) 23:57, 11. Jun. 2017 (CEST)

Diskussion

Unterstützung

1.  Pro Martin Kraft (Einreichende Person)
2.  Pro --FNDE 11:53, 20. Jun. 2017 (CEST)
3.  Pro --Avron (Diskussion) 20:19, 21. Jun. 2017 (CEST) Man kann zwar Standardgröße der Vorschaubilder in Pixeln in den Einstellungen wählen, aber das ist pro Person. Eine geeignete Einstellung unterscheidet sich aber erheblich vom Endgerät.
4.  Pro --Jü (Diskussion) 06:38, 22. Jun. 2017 (CEST)
5.  Pro --Smial (Diskussion) 10:32, 22. Jun. 2017 (CEST)
6.  Pro --Nichtich (Diskussion) 22:31, 23. Jun. 2017 (CEST)
7.  Pro --Alchemist-hp (Diskussion) 07:42, 24. Jun. 2017 (CEST)
8.  Pro --DianeAnna (Diskussion) 23:24, 25. Jun. 2017 (CEST)
9.  Pro Gestumblindi 11:32, 26. Jun. 2017 (CEST)
10.  Pro Sehr sinnvoll. Falls es aber doch Fälle geben sollte, bei denen eine fixe Bildgröße gut wäre, sollte man beim Einbinden eines Bildes die Möglichkeit haben, zwischen "flexibel" und "fix" zu wählen. --Eweht (Diskussion) 08:16, 27. Jun. 2017 (CEST)
11.  Pro --Ak ccm (Diskussion) 15:26, 28. Jun. 2017 (CEST)
12.  Pro --Kein Einstein (Diskussion) 16:04, 28. Jun. 2017 (CEST)
13.  Pro --Thomas Obermair 4 (Diskussion) 17:27, 28. Jun. 2017 (CEST)
14.  Pro -- hgzh 19:33, 29. Jun. 2017 (CEST)
15.  Pro --Snurb3010 (Diskussion) 22:40, 29. Jun. 2017 (CEST)
    
    

Dia-Rahmen bei Galeriebildern entfernen.

Was ist das Problem?

Die Diarahmen-artigen Ränder um Galeriebilder verschwenden ziemlich viel Platz und sorgen für eine kleiner Darstellung als nötig. Hier wurde entsprechend des mittlerweile überkommenen Prinzips des Skeuomorphismus die Erkennbarkeit der Bilder der Analogie zu Dias untergordnet. Von diesem Designprinzip ist man nicht umsonst bei Android, Windows und iOS schon lange abgekommen.

Man kann die Galerien zwar auf den Modus "packed" umstellen, der für eine größere Bilddarstellung sorgt. Aber einerseits ist das nicht der Standard (und wird deshalb nur von erfahreneren Nutzern genutzt) und andererseits ist das ziemlich buggy: Wenn an der Seite Info-Boxen oder andere Bilder angezeigt werden (oder auf einigen Auflösungen dorthin rutschen) zerstört es das in sich geschlossene Layout. Außerdem erscheinen in dieser Ansicht die Hochformate viel zu klein.

Wen betrifft das Problem besonders?

Alle Leser

Lösungsvorschlag

Rahmen im Standard entfernen und ein zeitgemäßeres auch mit seitlich angeordneten anderen Bilden funktionierendes Layout implementieren.

Vorschlagende Person

Martin K. (Diskussion) 23:59, 11. Jun. 2017 (CEST)

Diskussion

Und wie soll das bei File:Flag_of_Japan.svg gehen? Grüße --h-stt !? 18:38, 20. Jun. 2017 (CEST)

@H-stt: Das man den fetten grauen Kasten entfernt, bedeuted ja nicht automatisch, dass es gar keinen Rahmen haben dürfte. MMn wäre der in Vector übliche dünne graue Pixel-Rahmen durchaus vertretbar. // Martin K. (Diskussion) 18:42, 20. Jun. 2017 (CEST)

Unterstützung

1.  Pro Martin Kraft (Einreichende Person)
2.  Pro Jordi (Diskussion) 15:10, 20. Jun. 2017 (CEST) Wenn mögl. meinen Vorschlag einer "Border"-Option (Rahmen für Bilder auch in Galerien, s. o.) dabei mit berücksichtigen
3.  Pro --Fährtenleser (Diskussion) 16:41, 20. Jun. 2017 (CEST)
4.  Pro --Till.niermann (Diskussion) 21:00, 20. Jun. 2017 (CEST)
5.  Pro --Carl Ha (Diskussion) 22:14, 20. Jun. 2017 (CEST)
6.  Pro --Smial (Diskussion) 10:33, 22. Jun. 2017 (CEST)
7.  Pro --Magnus (Diskussion) 16:03, 22. Jun. 2017 (CEST)
8.  Pro --Alchemist-hp (Diskussion) 07:43, 24. Jun. 2017 (CEST)
9.  Pro --MBxd1 (Diskussion) 10:11, 24. Jun. 2017 (CEST) Grundsätzlich dafür. Ich möchte aber darauf hinweisen, dass dieser Vorschlag im umfassenderen Vorschlag Flexiblere Bildeinbindung als Ersatz für die Galeriefunktion bereits enthalten ist. Dort geht es um eine Darstellung wie einzeln eingebundene Bilder in freier Anordnung, mit Anwendbarkeit aller benutzerdefinierten Einstellungen.
10.  Pro --Mushushu (Diskussion) 16:47, 25. Jun. 2017 (CEST)
11.  Pro --DianeAnna (Diskussion) 23:05, 25. Jun. 2017 (CEST)
12.  Pro --Geolina ^{mente et malleo} ✎ 21:04, 27. Jun. 2017 (CEST)
13.  Pro --Pechristener (Diskussion) 21:09, 27. Jun. 2017 (CEST)
14.  Pro --Ak ccm (Diskussion) 15:27, 28. Jun. 2017 (CEST)
15.  Pro --Thomas Obermair 4 (Diskussion) 17:27, 28. Jun. 2017 (CEST)
16.  Pro -- hgzh 19:33, 29. Jun. 2017 (CEST)
17.  Pro --Snurb3010 (Diskussion) 22:38, 29. Jun. 2017 (CEST)
18.  Pro —DerHexer (Disk., Bew.) 23:42, 1. Jul. 2017 (CEST)
19. Abwartend --ProloSozz (Diskussion) 23:03, 2. Jul. 2017 (CEST) Sollte in den eigenen Einstellungen als Option verfügbar sein.
20.  Pro eine Platzverschwednung in der Mehrzahl der Fälle & zu zu kleinen Bildern führend. Der Standard sollte auf <gallery mode=packed heights=150px style="text-align:left"> oder <gallery mode=packed-overlay style="text-align:left" title="Video games adopting Simple DirectMedia Layer"> gesetzt werdenShaddim (Diskussion) 12:02, 9. Jul. 2017 (CEST)