Wikipedia:Umfragen/Technische Wünsche 2017/Schwesterprojekte

Umfrage Technische Wünsche 2017

Rubrik „Schwesterprojekte“

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.

Verbleiben in der mobilen Version beim Benutzen von Interwikilinks.

Was ist das Problem?

Wenn man mit Minerva einen Artikel in einer anderen Sprache lesen will (Aufruf des Menüs über das kleine Schriftzeichen-Symbol oben-links unterm Titel), wird man beim Wechsel zu einer anderen Sprache auf die Desktop-Version geleitet.

Wen betrifft das Problem besonders?

Alle Leute, die Minerva benutzen und manchmal die Sprache wechseln wollen

Lösungsvorschlag

Die Links, die einem angeboten werden sollten auf die mobile Version der Seite verlinken.

Vorschlagende Person

KPFC 💬 15:33, 29. Mai 2017 (CEST)

Diskussion

Unterstützung

1.  Pro KPFC (Einreichende Person)
2.  Pro --MB-one (Diskussion) 17:38, 19. Jun. 2017 (CEST)
3.  Pro DCB (Diskussion • Bewertung) 15:31, 20. Jun. 2017 (CEST)
4.  Kontra Die Mobile Version ist eh unbrauchbar, zudem Verbesserungsvorschläge meist als nicht umsetzbar abgelehnt werden. -- User: Perhelion 15:55, 23. Jun. 2017 (CEST)
5.  Pro --Marsupium (Diskussion) 18:07, 23. Jun. 2017 (CEST)
6.  Pro -- Freddy2001 ^DISK 12:13, 24. Jun. 2017 (CEST)
7.  Pro --Thomas Obermair 4 (Diskussion) 17:04, 28. Jun. 2017 (CEST)
8.  Pro --Fixuture (Diskussion) 21:14, 1. Jul. 2017 (CEST)
   
   

Ein leistungsstarkes und möglichst einfaches Tool zum Konvertieren von nicht-svg-Dateien in svg-Dateien.

Was ist das Problem?

Bei der Bearbeitung von Bilddateien ergibt sich immer wieder die Aufgabe, jpg-, png-, gif- oder andere Dateien in svg-Dateien zu konvertieren. Dazu ist es notwendig, sich entsprechende Programme aus dem Internet herunterzuladen, die häufig die erwartete Qualität nicht bringen und ohnehin keinen vertrauenswürdigen Eindruck machen.

Wen betrifft das Problem besonders?

jeden der Bilddateien bearbeitet

Vorschlagende Person

JostGudelius (Diskussion) 16:27, 29. Mai 2017 (CEST)

Diskussion

Anmerkung: Habe die Beschreibung "jpg" erweitert, da es auch viele andere Dateitypen gibt. --Œ̷͠²ð·¨´´̢́̕͘³͏¯̞̗ (Diskussion) 11:56, 30. Mai 2017 (CEST)

Hallo DerErbse und Œ̷͠²ð·¨´´̢́̕͘³͏¯̞̗, bis zum Beginn der Abstimmung am 19. Juni können Vorschlagende ihre Wünsche noch anpassen und z.B. Rückmeldungen aus der Diskussion einarbeiten. Am 19. Juni wird dann bei jedem Wunsch die Diskussion eingeklappt und ein Abschnitt „Abstimmung“ ergänzt. Darum habe ich eure {{Pro}}-Stimmen entfernt, den Kommentar von Œ̷͠²ð·¨´´̢́̕͘³͏¯̞̗ aber stehen lassen. -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 12:07, 30. Mai 2017 (CEST)

Alles klar, danke! --DerErbse (Diskussion) 23:06, 30. Mai 2017 (CEST)

Bilddateien in .svg umzuwandeln ist kein trivales Problem und der Arbeitsumfang, der benötigt wird, damit eine selbst entwickelte Lösung bessere Qualität als im Internet heruntergeladene Tools bietet, ist wahrscheinlich zu groß. ChristianKl (Diskussion) 11:41, 7. Jun. 2017 (CEST)

+1 Da JPG, PNG und GIF Rastergrafik-Formate sind, SVG ein Vektorgrafikformat ist, kann man dass nicht so einfach konvertieren, wie z.B. PNGs in JPGs o.ä.. Automatische Vektorisierung sind technisch sehr aufwändig und vom Ergebnis mit deutlichen Problemen verbunden, die meistens erhebliche Nacharbeiten nötig machen. Ich halte es ehrlich gesagt weder für sinnvoll noch für realistisch das innerhalb des Wikis zu tun. // Martin K. (Diskussion) 17:50, 10. Jun. 2017 (CEST)

Möglich wäre diese Konvertierung wohl nur für Grafikformate, wie ai (Adobe Illustrator), cdr (Corel Draw) fh10 (Freehand) oder dxf (AutoCAD). Aber diese Programme sind i.d.R. auch in der Lage SVGs zu exportieren... // Martin K. (Diskussion) 17:50, 10. Jun. 2017 (CEST)

@JostGudelius: Ich weiß nicht ob der Vorschlag ernst gemeint ist?

Ich hätte auch gerne eine Eierlegende Wollmilchsau. Ich bin in der WP:Grafikwerkstatt aktiv, ich wäre schon froh, wenn der Wiki-Konverter von SVG nach PNG funktionieren würde, siehe Wikipedia:WikiProjekt_SVG#Einschr.C3.A4nkungen_des_SVG-PNG-Renderers_der_Wikipedia,Wikipedia:Probleme_mit_SVGs, weil es gibt viele Funktionen die in SVGs verfügbar wären aber im Wikipedia-PNG einfach nicht dargestellt werden (z.B. Schriften entlang einer Kurve).  — Johannes Kalliauer - Diskussion | Beiträge 20:44, 21. Jun. 2017 (CEST)

+1 So und nicht anders. (Kommentar hierher verschoben) Man bekommt es doch noch nicht mal hin einen ordentlichen SVG-Renderer zu haben (was schon mal eine Grundvoraussetzung wäre, jeder Browser rendert besser). Es gibt genug SVG Programme, aber dem freien Programm Inkscape kann man gerne eine Finanzspritze geben. -- User: Perhelion 10:14, 24. Jun. 2017 (CEST)

Unterstützung

1.  Pro JostGudelius (Einreichende Person)
2.  Pro Kontrollstelle Kundl 18:44, 20. Jun. 2017 (CEST)
3.  Pro Conny 13:52, 21. Jun. 2017 (CEST).
4.  Kontra Diesen Vorschlag finde ich nicht realistisch. Ich konvertiere gelegentlich Rastergrafiken in SVG-Dateien und nehme dazu in der Regel Adobe Illustrator und das ist ja sicher kein unausgereiftes Programm. Trotzdem ist die Aufgabe häufig komplex und bedarf praktisch immer einer manuellen mehr oder minder ausführlichen Nachbearbeitung. Manchmal führt auch kein Weg daran vorbei, die SVG-Grafik ganz neu zu zeichnen, weil sie einfach sonst zu unprofessionell aussieht (da sind dann zwar die Kanten und Ecken scharf, aber man sieht ganz deutlich, dass das nachgezeichnet wurde). Eine einfache Lösung für ein so vielfältiges und komplexes Problem wird es nicht geben. --Furfur ^{⁂ Diskussion} 23:14, 21. Jun. 2017 (CEST)
5.  Kontra Wie Furfur und in der Disk. angemerkt. Das Vorhaben ist einfach nicht realistisch. // Martin K. (Diskussion) 23:22, 21. Jun. 2017 (CEST)
6.  Pro --Jü (Diskussion) 06:47, 22. Jun. 2017 (CEST)
7.  Kontra Wie Furfur und Martin K. Mit der "Lösung" SVG mit eingebettetem Bitmap ist auch keinem geholfen. --Magnus (Diskussion) 16:05, 22. Jun. 2017 (CEST)
8.  Pro --GodeNehler (Diskussion) 23:09, 22. Jun. 2017 (CEST)
9.  Kontra an der Realität vorbei (s. Diskussions-Kommentar) -- User: Perhelion 15:50, 23. Jun. 2017 (CEST)
10.  Kontra, nicht realistisch. Neuerstellung ist qualitativ besser als irgendwas halbautomatisches. Inkscape reicht dafür aus. -- Freddy2001 ^DISK 12:14, 24. Jun. 2017 (CEST)
11.  Pro --Thomas Obermair 4 (Diskussion) 17:05, 28. Jun. 2017 (CEST)
12.  Kontra --Gr1 (Diskussion) 12:36, 29. Jun. 2017 (CEST) Siehe Contra-Vorredner
13. Abwartend --ProloSozz (Diskussion) 23:10, 2. Jul. 2017 (CEST) Sieht an der Oberfläche zwar als "netter Wunsch" aus, geht aber in der Praxis völlig an der technischen Realität vorbei. Unrealistisches Unterfangen; WP ist zudem nicht Adobe oder Corel ...
14.  Kontra SVG taugt nix für Nachnutzer. --M@rcela 05:36, 3. Jul. 2017 (CEST)

(nachträglicher kommentar): ich fürchte, da bestehen schlicht enorme wissenslücken über das grundlegende wesen und die prinzipiellen unterschiede einer Rastergrafik (Pixelbild) und einer Vektorgrafik, und d was ein Vektorisierer (Tracer) tut. eigentlich schade, wir machen uns die mühe, gute artikel zu solchen themen zu schreiben, und nichtmal die eigene autorenschaft liest sie. was wir wohl viel dringender bräuchten, wäre ein tutorial "was ist vertrauenswürdige software im internet?": die opensource-community hat offenkundig große defizite, ihr anliegen und ihre selbstkontrollmechanismen an die nächste nutzergeneration zu vermitteln: das wäre doch ein sinnvoller einsatz unserer spendengelder. --W!B: (Diskussion) 08:48, 3. Jul. 2017 (CEST)

Den Lizenzhinweisgenerator für alle Lizenzen von Wikimedia Commons fit machen

Was ist das Problem?

Der Lizenzhinweisgenerator (LHG) erkennt noch nicht alle auf Commons zugelassenen Lizenzen und Hinweisbausteine (z.B. Persönlichkeitsrechte)

Wen betrifft das Problem besonders?

Nachnutzer von Wikimedia Commons

Lösungsvorschlag

Lizenztemplates und ggfs. benutzerspezifische Vorlagen mit Lizenzen sammeln, auswerten, ggfs. Änderungen beim Nutzer vorschlagen,

Anmerkungen

Ziel muss es sein, dass der LHG in Wikimedia Commons integriert wird, so dass jeder Nachnutzer die Möglichkeit hat, eine rechtssichere Nachnutzungsanweisung zu erhalten.

Vorschlagende Person

— Raymond ^Disk. 21:28, 29. Mai 2017 (CEST)

Diskussion

• Die Konflikte um mißliebige Abmahnpraktiken inklusive zweier gescheiterter Meinungsbilder mit teils unsäglichem Diskussionsverlauf haben immerhin überdeutlich gemacht, daß die Verwendung von freien Medien, wie sie in der Wikipedia bzw. auf commons angeboten werden, für Nachnutzer mit allerlei Unklarheiten und Unsicherheiten verbunden ist. Der LHG ist in der aktuellen Inkarnation zwar ein Schritt in die richtige Richtung, aber bisher muß ein Nachnutzer zum einen erst einmal wissen, daß es den gibt, und den dann auch noch finden. Um dann festzustellen, daß der in vielen Fällen die angebotenen Lizenzen nicht kennt und/oder mit benutzerdefinierten Lizenzvorlagen nicht zurande kommt. Nach meiner Erinnerung wurden Verbesserungen/Erweiterungen nach den ersten kritischen Kommentaren zwar versprochen, sind aber, wenn überhaupt, nur in Teilen durchgeführt worden. Ich stelle mir drei Schritte vor:
  1. Erweiterung des LHG auf alle auf commons zulässigen freien Lizenzen (POV: cc-ND oder cc-NC dürfen gerne ausgelassen werden...)
  2. Austausch der komischen Nachnutzungshilfe auf commons gegen den perfektionierten LHG
  3. Zwischenschaltung des LHG bei jeder Downloadmöglichkeit von Medien, also z.B. auch bei "Rechtsklick -> Speichern unter..." im Browser, sowohl auf commons als auch in den anderen Projekten. (Nebenbedingung: Sinnvollerweise sollten dann auch bei allen thumbs bzw. angebotenen Skalierungen fürderhin die EXIF/IPTC-Daten erhalten bleiben. Mediawiki tötet die derzeit.)

Man könnte nun einwenden, daß das ggf. für den Nachnutzer zusätzliche Mausklicks und Eingaben erfordert. Freilich sind solche zusätzlichen Aktionen ganz offensichtlich überhaupt kein Problem für Redaktionen oder Blogger, wenn sie sich Bildmaterial von Stockfoto-Anbietern besorgen. Bei denen sind gewöhnlich noch viel mehr Klicks notwendig - und man muß auch noch Geldtransfers anleiern.

Ich halte ein möglichst optimales und unübersehbares Informieren der Nachnutzer für den elementaren Schritt, illegale Nachnutzungen bzw. Lizenzverletzungen zu minimieren. Der Abmahnerei würde dadurch zumindest bei den "Nachnutzern mit guten Absichten" die Grundlage entzogen, denn die werden es "richtig machen", wenn sie wissen, wie es geht. --Smial (Diskussion) 16:00, 31. Mai 2017 (CEST)

Hallo Raymond Bei der Abstimmung wird die Diskussion eingeklappt, damit klar ist, worüber abgestimmt wird. Wenn die Hinweise in der Diskussion in Abstimmung für den Wunsch hilfreich sind, wäre es wichtig, dass du sie oben – z. B. unter „Was ist das Problem?“ oder „Lösungsvorschlag“ – ergänzt. -- Viele Grüße, Charlie Kritschmar (WMDE) (Diskussion) 19:57, 8. Jun. 2017 (CEST)

Es sollten nur Lizenzen unterstützt werden, die auch offiziell als frei anerkannt sind, um die Nachnutzung von (warum auch immer) auf Commons geduldeten unfreien Mehrfachlizenzierungen zu erschweren. —DerHexer (Disk., Bew.) 22:45, 1. Jul. 2017 (CEST)

Unterstützung

1.  Pro Raymond (Einreichende Person)
2.  Pro -- Marcus Cyron Reden 10:32, 19. Jun. 2017 (CEST)
3.  Pro --Leyo 10:34, 19. Jun. 2017 (CEST)
4.  Pro --Geolina ^{mente et malleo} ✎ 17:47, 19. Jun. 2017 (CEST)
5.  Pro Gestumblindi 23:51, 19. Jun. 2017 (CEST)
6.  Pro  _hugarheimur 08:11, 20. Jun. 2017 (CEST)
7.  Pro DCB (Diskussion • Bewertung) 15:32, 20. Jun. 2017 (CEST)
8.  Pro --Smial (Diskussion) 17:30, 20. Jun. 2017 (CEST)
9.  Pro --M@rcela 17:35, 20. Jun. 2017 (CEST)
10.  Pro // Martin K. (Diskussion) 18:03, 20. Jun. 2017 (CEST)
11.  Pro --jcornelius  11:45, 21. Jun. 2017 (CEST) absolut!
12.  Pro Conny 13:52, 21. Jun. 2017 (CEST).
13.  Pro -- Michi 19:38, 21. Jun. 2017 (CEST)
14.  Pro --NearEMPTiness (Diskussion) 21:38, 21. Jun. 2017 (CEST)
15.  Pro --Jü (Diskussion) 06:48, 22. Jun. 2017 (CEST)
16.  Pro --Suriyaa Kudo · Archiv (Diskussion) 13:36, 22. Jun. 2017 (CEST)
17.  Pro --Magnus (Diskussion) 16:06, 22. Jun. 2017 (CEST)
18.  Pro --TypeZero (Diskussion) 17:52, 22. Jun. 2017 (CEST)
19.  Pro -- User: Perhelion 15:57, 23. Jun. 2017 (CEST)
20.  Pro --Nichtich (Diskussion) 22:27, 23. Jun. 2017 (CEST)
21.  Pro -- Freddy2001 ^DISK 12:15, 24. Jun. 2017 (CEST)
22.  Pro --Divof (Diskussion) 19:41, 24. Jun. 2017 (CEST)
23.  Pro --DianeAnna (Diskussion) 20:45, 25. Jun. 2017 (CEST)
24.  Pro NNW 16:34, 27. Jun. 2017 (CEST)
25.  Pro --Incabell (Diskussion) 17:54, 27. Jun. 2017 (CEST)
26.  Pro --Thomas Obermair 4 (Diskussion) 17:05, 28. Jun. 2017 (CEST)
27.  Pro --Ak ccm (Diskussion) 23:58, 28. Jun. 2017 (CEST)
28.  Pro KPFC 💬 23:04, 29. Jun. 2017 (CEST)
29.  Pro --1971markus ^{⇒ Laberkasten ...} 23:32, 29. Jun. 2017 (CEST)
30.  Pro —SDKmac (Disk., Bew.) 02:23, 30. Jun. 2017 (CEST)
31.  Pro --Sebastian Wallroth 09:06, 1. Jul. 2017 (CEST)
32.  Pro -- Mboesch (Diskussion) 11:44, 1. Jul. 2017 (CEST)
33.  Pro --Entbert (Diskussion) 16:17, 2. Jul. 2017 (CEST)
34.  Pro bezüglich der Erweiterung des LHG auf alle auf commons zulässigen freien Lizenzen,  Neutral bezüglich allem weiteren. -- X:: black ::X (Diskussion) 22:33, 2. Jul. 2017 (CEST)
    
    

Commons: Erweiterung des Upload-Tools für Bilder mit automat. Verweis auf Ursprungsdatei bei veränderten Bildern

Was ist das Problem?

Wenn ich eine Bilddatei verändere und mit einem neuen Namen speichere, wünsche ich mir ein Feld mit einem automatischen Link zur Ursprungsdatei und deren Lizenz

• Was möchtest du machen und warum? In Wikivoyage stehe ich öfters vor der Aufgabe, Pläne mit englisch-sprachiger oder nicht-lateinischer Legende einzudeutschen.
• Welche Schritte durchläufst du dabei? Beim Upload mit dem Assistenten stehe ich vor dem ersten Schritt "eigene Arbeit" oder "nicht eigene Arbeit": ist die Arbeit an einem Plan mit neuer Einfärbung und neuer Legende nun ersteres oder zweites... Eine dritte Option "Abwandlung einer Datei unter einer CC-Lizenz" mit der Möglichkeit, auf das ursprüngliche File und dessen Autor automatisch zu verlinken, wäre hilfreich.
• Welche Probleme treten auf? Ich meine, ich hätte schon eine Vorlage für "abgewandelte Datei" o.ä. gesehen, fand aber keinen Hinweis darauf in der Doku. Die Abwandlung der bestehenden Bilddatei (beispielsweise Horizont gerade ausrichten oder Beschnitt optimieren) überschreibt ja das Ursprungsfile, was ich gerade nicht möchte, sondern das File mit Link auf die Ursprungsdatei in einer neuen Sprachversion speichern.

Wen betrifft das Problem besonders?

Autoren von Wikivoyage

Lösungsvorschlag

Siehe oben, entweder im Assistenten auf der ersten Seite ein weiterer Radiobutton oder im weiteren Verlauf (dort wo Koordinaten, Kategorien, etc. angegeben werden können ein neues Feld "Bilddatei basierend auf...., Autor ..." wäre hilfreich.

Anmerkungen

Auch das "Formular - Bisherige Hochladeart" stellt den Newbie vor Herausforderungen, am ehesten würde ich "Es stammt von woanders" anklicken und komme dann wieder auf ein komplexes Formular mit Lizenzbausteinen, etc.

Vorschlagende Person

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

Diskussion

Zunächst einmal wäre das nicht nur für Autoren von Wikivoyage sinnvoll, aber: Sieh dir bitte c:Commons:derivativeFX an. Und die Vorlage für abgewandelte Dateien ist eigentlich ein zusammengehörendes Paar {{Derivative versions}} und {{Derived from}}. — Speravir – 02:22, 30. Mai 2017 (CEST)

Unterstützung

1.  Pro Mboesch (Einreichende Person)
2.  Pro --MB-one (Diskussion) 17:41, 19. Jun. 2017 (CEST)
3.  Pro -- Karl432 (Diskussion) 21:34, 19. Jun. 2017 (CEST)
4.  Pro Gestumblindi 23:54, 19. Jun. 2017 (CEST) Im Prinzip geht es also darum, so etwas wie das Toollabs-Tool derivativeFX direkt auf Commons zu integrieren. Ich würde das begrüssen, auch weil man bei Toollabs nie weiss, was gerade funktioniert (derivativeFX war lange nicht nutzbar).
5.  Pro --M@rcela 17:36, 20. Jun. 2017 (CEST) Ich möchte den Reworkhelper wiederhaben!
6.  Pro --jcornelius  11:45, 21. Jun. 2017 (CEST)
7.  Pro Siehe phab:T110409 und phab:T69283. --El Grafo _(COM) 16:09, 22. Jun. 2017 (CEST)
8.  Pro Allerdings wie Speravir schon sagt, redundant zu derivativeFX. -- User: Perhelion 19:09, 23. Jun. 2017 (CEST)
9.  Pro -- Freddy2001 ^DISK 12:15, 24. Jun. 2017 (CEST)
10.  Pro --Thomas Obermair 4 (Diskussion) 17:06, 28. Jun. 2017 (CEST)
11.  Pro --Sebastian Wallroth 09:06, 1. Jul. 2017 (CEST)
12.  Pro --Sitacuisses (Diskussion) 14:40, 2. Jul. 2017 (CEST)
    
    

Wikimedia-Karten: Möglichkeit, die Sprachen der Labels zu wählen, um Karten mit nicht lateinischem Schriftsatz für Europäer lesbar zu machen.

Was ist das Problem?

Mit dem Einsatz von Markern, POI (Points of Interest) und dem Aufruf von dynamischen Karten wird als Standard nur der lokale Zeichensatz für die Labels (Orts-, Strassen, Flussbezeichnungen) angezeigt, eine Möglichkeit der Wahl einer anderen Sprache resp. der Umschaltung auf englischsprachige oder gar deutsche Labels ist nicht möglich, obschon diese Daten im OSM-Datensatz existieren.

• Was möchtest du machen und warum? In den Ortsartikeln in Wikivoyage werden Sehenswürdigkeiten, Hotels, Bahnhöfe, etc. nicht nur enzyklopädisch aufgeführt, sondern mit Markern / POI-Markern versehen, dass der Reisende vor Ort die Chance hat, diese zu finden. In Gebieten mit nicht-lateinischem Zeichensatz (Griechenland, Israel, arabischsprachige Länder, Asien...) wird die Karte nur mit den Labels in lokaler Sprache angebote, was dem Reisenden bei der Orientierung nicht viel weiter hilft, wenn er beispielsweise des Arabischen oder Koreanischen nicht mächtig ist...

Nach Informationen in OSM-Foren werden die Karten für die Kartographen als Standard in ortsüblicher Sprache angeboten. Für Nutzer, welche die Labels in anderen Sprachen sehen möchten (beispielsweise englisch), müsste die Karte vom Benutzer resp. der Benutzerplattform gerendert werden. Die englischsprachigen Orts- / Strassennamen etc. sind oftmals bereits in OSM erfasst, können aber nicht angezeigt werden, da sich für das Rendering der Wikimedia-Karte nicht auf die verschiedenen Sprachen umschalten lässt.

• Welche Schritte durchläufst du dabei?

Ich setze Marker mit Koordinatenangabe, kann aber die Ausgabe der englischsprachigen Labels der Orts- / Strassen- / Fluss- / Bergbezeichnungen bisher nicht bewirken.

• Welche Probleme treten auf?

Die Karten sind für Reisende in Ländern mit nicht-lateinischem Schriftsatz von geringem Nutzen, da man sich quasi als Analphabet zurechtfinden muss - vielfach muss der Reisende parallel die Stellen in Google Maps suchen, wo die Labels in englischer Sprache ausgegeben werden.

Wen betrifft das Problem besonders?

Autoren und User von Wikivoyage, welche aus dem europäischen Raum kommen und fremde Schriftsätze nicht lesen können

Lösungsvorschlag

Falls vorhanden, kurz beschreiben: Gibt es schon eine Idee zur Problemlösung oder Tools/Gadgets, die das Problem jetzt schon angehen? In der deutschen Open Stretmap werden die lateinischen Labels angezeigt (es scheint also irgendwie zu funktionieren), nicht aber bei OSM.org oder der Schweizer OSM.

Ein Schalter zur Wahl des Schriftsatzes mit wählbarer Priorisierung wäre extrem hilfreich (für wv.de 1. Priorität deutsch, 2. Priorität engl., 3. Priorität Lokalsprache (d.h. wenn keine anderen Labels hinterlegt sind); für andere Sprachversionen könnten die Prioritäten entsprechend angepasst werden, französisch heisst Kairo ja Le Caire, etc., was dann mit 1. Prio französisch entsprechend ausgegeben werden könnte.

Anmerkungen

Eine Sprachauswahl der Labels dürfte längerfristig sogar für WP-Nutzer hilfreich sein.

Vorschlagende Person

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

Diskussion

Unterstützung

1.  Pro Mboesch (Einreichende Person)
2.  Pro Conny 13:54, 21. Jun. 2017 (CEST).
3.  Pro --Jossi (Diskussion) 13:50, 22. Jun. 2017 (CEST)
4.  Pro --Dominic Z. (Diskussion) 18:20, 22. Jun. 2017 (CEST)
5.  Pro --GodeNehler (Diskussion) 23:10, 22. Jun. 2017 (CEST)
6.  Pro --Marsupium (Diskussion) 18:10, 23. Jun. 2017 (CEST)
7.  Pro --Thomas Obermair 4 (Diskussion) 17:06, 28. Jun. 2017 (CEST)
8.  Pro --Frze> ^{> Disk} 11:51, 30. Jun. 2017 (CEST)
9.  Pro --Sebastian Wallroth 09:07, 1. Jul. 2017 (CEST)
10.  Pro --Claudius (Diskussion) 12:23, 1. Jul. 2017 (CEST)
11.  Pro -- X:: black ::X (Diskussion) 22:42, 2. Jul. 2017 (CEST)
12.  Pro --ProloSozz (Diskussion) 23:13, 2. Jul. 2017 (CEST) Bitte dann auch beide Schreibweisen vorsehen.
    
    

Vereinfachtes Auffinden von Commons-Kategorien

Was ist das Problem?

Wer Bilder auf Commons möglichst umfassend genau kategorisieren möchte, ist darauf angewiesen, die meist englischsprachigen Commonscats irgendwie zu kennen. Das ist bei einfachen & gebräuchlichen Begriffen, wie Aachener Dom > Aachen cathedral noch trivial; langwierig wird die Suche bei Fachbegriffen, die man nicht zwingend in englisch kennen muss bzw. nicht unter dem Begriff, den man persönlich als zutreffend betrachtet, angegelegt wurden. Bleibt also der Umweg über die Wikipedia: Wenn es einen deutschen Artikel gibt, kann man hoffen, dass die commonscat verlinkt ist, andernfalls muss man schauen, ob man in der englischsprachigen WP etwas findet oder kann dann ggf. über den Umweg über Wikidata versuchen, die exakte Kategorie herausfinden. Diese Procedur ist extrem umständig und gerade, wenn man massenhaft z.B. bei WLE nachkategorisiert, unproduktiv und zeitfressend.

Wen betrifft das Problem besonders?

User, die auf commons Bilder selbst hochladen bzw. unkategorisierte Bilder in die Kategorien einsortieren.

Lösungsvorschlag

Ich würde mir wünschen, dass wenn man einen deutschen Begriff, z.B. Gletschertopf in eine Suchmaske eingibt, eine Auswahlmöglichkeit von passenden commons-Kategorien – hier z.B. giants kettles angezeigt wird. Ich könnte mir eine Verknüpfung / Suchschleife über Wikidata vorstellen. Auch eine Verknüfung zur de-WP wäre möglich, obwohl ich zu bedenken gebe, dass natürlich dort noch längst nicht alle (Fach-)Artikel existieren.

Vorschlagende Person

Geolina ^{mente et malleo} ✎ 09:49, 30. Mai 2017 (CEST)

Diskussion

• Vielleicht kann man den Wunsch verallgemeinern in dem Sinne, dass auf Basis von Dateiname, Beschreibung und möglicherweise vorhandenen GPS-Koordinaten Vorschläge für Kategorien gemacht werden. --13:26, 30. Mai 2017 (CEST) (ohne Name signierter Beitrag von Aschroet (Diskussion | Beiträge))

• Wäre es möglich für die Bezeichner der Kategorien abstrakte (interne) Namen zu verwenden und je nach Spracheinstellung den übersetzten Namen anzuzeigen und zu verwenden?
  Beispiel:
  • Abstrakt = Cologne Cathedral
  • Deutsch = Kölner Dom
  • Spanisch = Catedral de Colonia
  • Englisch = Cologne Cathedral

Noch besser wäre es, wenn man die Kategorien von Wikimedia Commons und Wikipedia vereinheitlichen würde (keine unterschiedlichen Bezeichner für die gleichen Objekte).

--F. Riedelio (Diskussion) 18:18, 30. Mai 2017 (CEST)

• Wegen der in weiten Teilen äußerst inkonsistenten Kategorisierung auf commons dürfte das ein recht komplexes Unterfangen sein, trotzdem ein sehr wünschenswertes Tool. Die Sache mit den "internen" Namen und Übersetzungen wäre schick, ich weiß nicht, wie oft ich schon wikipediert oder gegoogelt habe, um die englische Bezeichnung für ein Objekt herauszufinden, um über den englischen Wikipedia-Artikel ähnliche Bilder zu finden und über diese Bilder wiederum die geeignete Kategorie... --Smial (Diskussion) 16:20, 31. Mai 2017 (CEST)

• F. Riedelio, die Kategorien kann man nicht sinnvoll vereinheitlichen, genauso wie man das Kategoriesystem der deutschen und der englischen oder der … Wikipedia nicht sinnvoll vereinheitlichen kann.
  

Hinweis: Es gibt schon seit einiger Zeit ein Projekt Structured Data, das das Problem vereinfachen würde, wenn ich es nicht falsch verstanden habe, da man dann Kategorien übersetzen könnte, vgl. Commons:Strukturierte Daten. Mir ist der Entwicklungsstand aber nicht bekannt. (Lydia Pintscher kann dazu vermutlich mehr sagen.) — Speravir – 22:43, 31. Mai 2017 (CEST)

Danke für den Ping. Der aktuelle Stand ist: Es gibt ein erstes sehr rudimentäres Testsystem. Da fehlt aber noch eine ganze Menge. Im Moment arbeiten die WMF und mein Team an den Grundlagen. In den nächsten Monaten wird es dann an die sichtbareren Teile gehen. Ich gehe davon aus, dass 2018 die ersten Sachen auf Commons zu nutzbar sind. Davor wird das Testsystem weiter ausgebaut und mit den Commons-Beitragenden getestet und verbessert. --Lydia Pintscher (WMDE) (Diskussion) 16:24, 7. Jun. 2017 (CEST)

Danke, Lydia. Liege ich denn damit richtig, dass dann auch die Kategorien übersetzt werden können (bzw. wohl so wie bei Wikidata eigentlich eine kryptische ID besitzen)? — Speravir – 19:32, 7. Jun. 2017 (CEST)

Im Prinzip ja, genau. Es ist allerdings für mich noch etwas schwammig wie genau Kategorien mit Wikidata Items interagieren werden und wie das dann im Detail aussieht. --Lydia Pintscher (WMDE) (Diskussion) 19:39, 7. Jun. 2017 (CEST)

Geht nicht - gibt's nicht.

Die Behauptung, dass man die Kategorien nicht sinnvoll vereinheitlichen kann halte ich ohne weitere Begründung nicht für hilfreich.

--F. Riedelio (Diskussion) 10:53, 6. Jun. 2017 (CEST)

• Gibt es in WikiData nicht längst eine Verknüpfung zwischen den verscheidensprachigen Artikel einerseits und der Commons-Cat andererseits?! Könnte man die nicht automatisch in der Seitenspalte bei den Sprachversionen anzeigen, statt überall manuell {{Commonscat}} zu setzen? // Martin K. (Diskussion) 14:58, 12. Jun. 2017 (CEST)

@Martin Kraft: Nicht grundsätzlich, das muss erst einmal von jemandem eingefügt werden. Und dann hängt es auch noch davon ab, an welcher Stelle die Kategorie in einen Datensatz eingetragen wird, ob sie dann auf der linken Seite angezeigt wird. — Speravir – 23:48, 15. Jun. 2017 (CEST)

Unterstützung

1.  Pro Geolina163 (Einreichende Person)
2.  Pro sk (Diskussion) 16:57, 21. Jun. 2017 (CEST)
3.  Pro -- Michi 19:38, 21. Jun. 2017 (CEST)
4.  Pro --GodeNehler (Diskussion) 23:11, 22. Jun. 2017 (CEST)
5.  Pro --XRay ^Disk. 20:44, 25. Jun. 2017 (CEST)
6.  Pro --Thomas Obermair 4 (Diskussion) 17:06, 28. Jun. 2017 (CEST)
7.  Pro flunk 21:04, 29. Jun. 2017 (CEST)
8.  Pro --ManfredK (Diskussion) 22:29, 29. Jun. 2017 (CEST)
9.  Pro --Lars (User:Albinfo) 22:40, 29. Jun. 2017 (CEST) müsste ja mit Wikidata gut machbar sein
10.  Pro --1971markus ^{⇒ Laberkasten ...} 23:32, 29. Jun. 2017 (CEST)
11.  Pro -- Mboesch (Diskussion) 11:45, 1. Jul. 2017 (CEST)
12.  Pro --Fixuture (Diskussion) 21:14, 1. Jul. 2017 (CEST)
13.  Pro --Sitacuisses (Diskussion) 14:45, 2. Jul. 2017 (CEST)
14.  Pro --C₂₁H₂₂N₂O₂ (Diskussion) 22:29, 2. Jul. 2017 (CEST)
15.  Pro --Zaccarias (Diskussion) -- @C21H22N2O2: bitte korrigiere deine Signatur, da stimmt was nicht, meine Abstimmung wurde abgeschnitten. -- 19:16, 2. Jul. 2017 (CEST)
16.  Pro -- X:: black ::X (Diskussion) 22:46, 2. Jul. 2017 (CEST)
    
    

Wiederherstellung der Funktion des Pointers in Bing Maps

Was ist das Problem?

Wie ich bereits auf Wikipedia Diskussion:WikiProjekt Georeferenzierung#Entfernung von Bing Maps aus der Vorlage:GeoTemplate und Vorlage:All Coordinates und Vorlage:Linked Coordinates beschrieben habe wird nach einem Aufruf des GeoHack und anschließendem Aufruf der Bing Maps kein Pointer auf der Bing Maps angezeigt. Auch das Zoomen der Karte funktioniert nicht mehr. Das ist bereits seit September 2016 so! Es ist auf Bing Maps also derzeit nicht mehr möglich den georeferenzierten Ort auf der Karte auszumachen. Es werden also keine Pointer mehr angezeigt wenn auf Bing Maps über Vorlage:GeoTemplate zugegriffen wird, ebenso werden keine Objekte auf der Bing Maps mehr angezeigt die in Artikeln oder Kategorien über die Vorlage:All Coordinates und Vorlage:Linked Coordinates aufgerufen werden. Bing Maps bietet außer der Straßenkarte Satelittenbilder und Bilder aus der Vogelpersektive bzw. Schrägluftbilder, es sollte meiner Meinung nach wieder eine Funktion herbeigeführt werden. Wenn das wieder hergestellt werden kann, soll die Bing Maps natürlich nicht aus den genannten Vorkagen entfernt werden.

Wen betrifft das Problem besonders?

Es betriftt alle Wikimediaprojekte - also alle Sprachversionen der Wikipedia, Wikivoyage, Wikinews, Commons usw. Also alle die auf den GeoHack zugreifen.

Lösungsvorschlag

Es muss sicher eine Kommunikation mit Bing hergestellt werden. Die Parameter auf https://msdn.microsoft.com/en-us/library/dn217138.aspx führen nicht zum Erfolg.

Vorschlagende Person

2003:DE:3D7:732F:F1EB:93:C5AB:860D 22:16, 30. Mai 2017 (CEST)

Diskussion

Unterstützung

1.  Pro 2003:DE:3D7:732F:F1EB:93:C5AB:860D (Einreichende Person)
2.  Pro Conny 13:54, 21. Jun. 2017 (CEST).
3.  Pro --Thomas Obermair 4 (Diskussion) 17:07, 28. Jun. 2017 (CEST)
4.  Pro --Sebastian Wallroth 09:08, 1. Jul. 2017 (CEST)
5.  Pro -- X:: black ::X (Diskussion) 22:50, 2. Jul. 2017 (CEST)
   
   

Commons: Texterkennung bei Inschriften auf fotografierten Denkmälern u.ä.

Was ist das Problem?

Es werden viele Bilder von Denkmälern, Inschriftenplatten gemacht. Diese Angaben sind ein wertvoller Teil der Bildbeschreibung. Es ist jedoch oft müßig die Daten abzutipppen bzw. es fehlt die Kompetenz (z. B. bei kyrillischen Buchstaben)

Wen betrifft das Problem besonders?

Fotografen

Lösungsvorschlag

Texterkennungssoftware für abfotografierte Texte

Anmerkungen

Vorrangig soll um solche Fotos gehen File:Gedenktafel schulstr.JPG, File:Sfbkappputsch.JPG oder File:Sowjet ehrenmal schönholzer Heide jan2017 - 21.jpg

Vorschlagende Person

 ^Thomas 11:35, 31. Mai 2017 (CEST)

Diskussion

@Z thomas: Das dürfte technisch alles andere als trivial sein. Das hier geht noch. Aber das hier dürfte an die Grenze des Machbaren gehen. Das ist ja schon fast ein Captcha - so einfarbig und mit diesen niedrigen Kontrasten. Eine normale OCR-Software dürfte an sowas scheitern, da müsste man meiner Einschätzung nach schon auf neuronale Netze o.ä. setzen. Und da stellt sich für mich die Frage ob der erwartbare Nutzen diesen Aufwand rechtfertigt. // Martin K. (Diskussion) 18:11, 20. Jun. 2017 (CEST)

Unterstützung

1.  Pro Z thomas (Einreichende Person)
2.  Pro DCB (Diskussion • Bewertung) 15:34, 20. Jun. 2017 (CEST)
3.  Pro Conny 13:54, 21. Jun. 2017 (CEST).
4.  Kontra Halte ich nicht für realistisch. --Magnus (Diskussion) 16:07, 22. Jun. 2017 (CEST)
5.  Pro --GodeNehler (Diskussion) 23:11, 22. Jun. 2017 (CEST)
6.  Pro --Nichtich (Diskussion) 22:27, 23. Jun. 2017 (CEST)
7.  Pro -- Freddy2001 ^DISK 12:16, 24. Jun. 2017 (CEST)
8.  Pro Mache ich derzeit manuell für alle Texte im Bild. Eine automatische Erkennung von Texten in Bildern habe ich schon mal programmiert, funktionierte, aber nicht ausreichend gut. Ein Kontroll-/Korrekturschritt ist nötig. --XRay ^Disk. 20:48, 25. Jun. 2017 (CEST)
9.  Pro --Thomas Obermair 4 (Diskussion) 17:08, 28. Jun. 2017 (CEST)
10.  Pro --Gr1 (Diskussion) 12:38, 29. Jun. 2017 (CEST) Natürlich wird das nicht perfekt sein. Aber eine Bildersuche an Hand der im Bild erwähnten Texte wäre genial.
11.  Pro --Sebastian Wallroth 09:10, 1. Jul. 2017 (CEST)
12.  Neutral Mit OCR ist man anscheinend noch nicht so weit, dass die ohne viel zu hohen Aufwand möglich wäre. Außerdem gibt es in jedem Fall viele Fehler. Von daher gibt es wichtigeres bzw sollte man damit wohl eher warten. --Fixuture (Diskussion) 21:17, 1. Jul. 2017 (CEST)
    
    

Benachrichtigung zu Löschdiskussionen bei Interwiki-Artikeln

Was ist das Problem?

Es kommt hin und wieder vor dass jemand in mehreren Sprachversionen übersetzungen des selben Artikels einstellt. Ein koordiniertes Vorgehen ist momentan nicht möglich, jeder muss selber die Interwikis überprüfen. Als Beispiel gibt es Wikipedia:Löschkandidaten/21._April_2017#Flaggen_der_Verwaltungseinheiten_der_Nguyen-Dynastie

Wen betrifft das Problem besonders?

Eingangskontrolleure

Vorschlagende Person

DWI (Diskussion) 13:10, 31. Mai 2017 (CEST)

Diskussion

Unterstützung

1.  Pro Der-Wir-Ing (Einreichende Person)
2.  Pro --Thomas Obermair 4 (Diskussion) 17:08, 28. Jun. 2017 (CEST)
3.  Pro --ProloSozz (Diskussion) 23:15, 2. Jul. 2017 (CEST)
   
   

Links auf diese Seite auch projektübergreifend

Was ist das Problem?

Auf Commons gibt es die Möglichkeit, in der Dateibeschreibung auf Artikel in den WP-Sprachversionen zu verlinken. Wenn in der jeweiligen WP der Artikel verschoben wird, kann man sich über "Links auf diese Seite" die verlinkten Artikel in der jeweiligen Sprachversion anzeigen lassen. Links in den Schwesterprojekten werden nicht angezeigt.

Wen betrifft das Problem besonders?

Autoren, die Dateien verschieben

Lösungsvorschlag

"Links auf diese Seite" projektübergreifend gestalten

Vorschlagende Person

 ^Thomas 13:27, 31. Mai 2017 (CEST)

Diskussion

Das hat gar nichts mit Commons zu tun, sondern ist eine grundlegende Problematik aller Interwiki-Links. — Speravir – 23:50, 15. Jun. 2017 (CEST)

Unterstützung

1.  Pro Z thomas (Einreichende Person)
2.  Pro Zabia (Diskussion) 17:31, 20. Jun. 2017 (CEST)
3.  Pro --Thomas Obermair 4 (Diskussion) 17:09, 28. Jun. 2017 (CEST)
4.  Pro --Fixuture (Diskussion) 21:18, 1. Jul. 2017 (CEST)
5.  Pro —DerHexer (Disk., Bew.) 22:50, 1. Jul. 2017 (CEST)
6.  Pro -- X:: black ::X (Diskussion) 22:55, 2. Jul. 2017 (CEST)
   
   

Commons: Assistent zur Erstellung von Commons-Personenkategorien auf Basis des Wikipedia-Artikels

Was ist das Problem?

Auf Commons sind in übergreifenden Kategorien zahlreiche Bilder zu Einzelpersonen abgelegt, zu denen noch keine individuelle Personenkategorie existiert. Bei der Erstellung der Personenkategorie müssen etliche Arbeitsschritte manuell durchgeführt werden, obwohl die dazu notwendigen Daten im Wikipedia-Personenartikel bereits in strukturierter Form vorliegen: DEFAULTSORT eintragen, Tätigkeitskategorie umwandeln, Regionalkategorie umwandeln, Geburtsjahr- und Todesjahrkategorie eintragen, Interwikilink eintragen. Das Problem ist dabei nicht, die passenden Commons-Kategorien zu bestimmen (bei der Grundkategorisierung von Personen ist das eine sehr überschaubare Zahl von Möglichkeiten), sondern die langweilige Umwandlung von z. B. Kategorie:Geboren 1912 in c:Category:1912 births. Ein paarmal macht man das gerne, ab Kategorie 200 wird es fürchterlich öde.

Wen betrifft das Problem besonders?

Unmittelbar Commons-Äufräumer, die systematisch Personenkategorien anlegen. Mittelbar alle Commons-Nutzer auf der Suche nach Personenbildern und Wikipedia-Nutzer, die den Commonscat-Link unter Personenartikeln praktisch finden.

Lösungsvorschlag

Tool, das (a) aus einem frei wählbaren Wikipedia-Artikel die Commons-relevanten Informationen ausliest, dann (b) auf Basis einer nutzereditierbaren Kategorien-Konkordanzliste übersetzt und (c) das Ergebnis als kopierbaren Text zum Übertrag in die Commons-Kategorienseite ausgibt.

Anmerkungen

Es gibt ein vergleichbares Tool namens "MultiDesc" (https://tools.wmflabs.org/multidesc/), das bei der Seitenbeschreibung und bei den Interwikis hilft - aber leider nicht bei den Kategorien. Notwendiges Zwischenelement wäre da wohl die Konkordanzliste, die dem Tool sagt, dass es aus Kategorie:Reichstagsabgeordneter (Deutsches Kaiserreich) bitte c:Category:Members of the German Reichstag (1871-1918) machen soll. Eine solche Liste lässt sich inhaltlich ziemlich einfach erstellen - aber es fehlt mir das Tool, das sie dann einsetzt...

Vorschlagende Person

Rudolph Buch (Diskussion) 14:26, 31. Mai 2017 (CEST)

Diskussion

Unterstützung

1.  Pro Rudolph Buch (Einreichende Person)
2.  Pro DCB (Diskussion • Bewertung) 15:34, 20. Jun. 2017 (CEST)
3.  Pro --Thomas Obermair 4 (Diskussion) 17:09, 28. Jun. 2017 (CEST)
4.  Pro -- X:: black ::X (Diskussion) 22:58, 2. Jul. 2017 (CEST)
   
   

Commons: Erstellen einer Übersicht, wo in den Schwesterprojekten und in den WP-Sprachversionen eigene Fotos genutzt werden

Was ist das Problem?

Man hat keine Möglichkeit zu sehen, wo alle eigenen hochgeladenen Dateien genutzt werden. Es geht nur, indem man jedes Fotos einzeln öffnet

Wen betrifft das Problem besonders?

Fotografen

Lösungsvorschlag

Der Nutzer muss auf Commons die Möglichkeit haben, sich eine Übersicht anzeigen zu lassen, in der er all seine in der WP und den Schwesterprojekten genutzten Fotos aufgelistet bekommt (Die Nutzung in den Commons-Galerien zählt auch dazu). Die Funktion sollte ähnlich wie die Spezialseite "Dateiliste", die über "Dateien" aufrufbar ist, aufgerufen werden.

Anmerkungen

Entwicklungsansätze sind durch @Kolossos: vorhanden Benutzer_Diskussion:Z_thomas/Archiv2016#Bilder-Nutzung_auf_Commons_.26_Tabellenauswertung (für die ideenfindung). Darüber hinaus gibt es das Tool GLAMorous, das die gewünschten Funktionen bietet.

Vorschlagende Person

 ^Thomas 15:53, 31. Mai 2017 (CEST)

Diskussion

c:Commons:MyGallery öffnen, das Skript laden und auf eines der Fragezeichen klicken, die sich rechts unten in den Vorschaubildern befinden (hinter der Funktionalität steckt das Skript Global Usage Badges, das man in seinen Einstellungen auch für alle Galerien aktivieren kann). Es wird allerdings nicht zwischen Nutzung in Commons und externer Nutzung unterschieden und ist wohl auch nicht vollkommen zuverlässig. — Speravir – 23:09, 31. Mai 2017 (CEST)

Zweite Möglichkeit: Das Tool GLAMorous. Dort kann man sich die Nutzung der Dateien eines Benutzers oder einer Kategorie anzeigen lassen. Ich hatte es neulich noch genutzt, aber jetzt gerade funktioniert es leider nicht. -- Reise Reise (Diskussion) 08:41, 1. Jun. 2017 (CEST)

danke @Speravir, Reise Reise: für eure beiträge

wenn ich das richtig verstanden habe, liste "mygallery" die uploads eines nutzers auf. aber nicht in welchen WP oder Schwesterprojekten sie genutzt werden. das entspricht also nicht meinem wunsch.

GLAMorous muss ich testen, wenn es wieder funktioniert. ich hatte jetzt nur meinen nutzernamen eingegeben (dateien gewählt und wieder deaktiviert) aber es gab keine ergebnisse. gruß -- ^Thomas 08:54, 1. Jun. 2017 (CEST)

MyGallery gibt zunächst einmal an, ob ein Bild genutzt wird. Dann könnte man auf dieses Bild gehen und nachsehen. Aber GLAMorous ist in der Tat deutlich besser geeignet für das, was Du willst. — Speravir – 19:55, 1. Jun. 2017 (CEST)

das versteh ich nicht. mygallery listet all meine bilder auf. z. B. File:Feuerwehrgerätehausnaustadt1.jpg und das ist nirgends eingebunden. gruß -- ^Thomas 09:24, 2. Jun. 2017 (CEST)

@Z thomas: GLAMorous läuft wohl wieder: Nutzung deiner Fotos in WMF-Projekten. -- Reise Reise (Diskussion) 10:02, 2. Jun. 2017 (CEST)

@Reise Reise: danke! cool. GLAMorous macht quasi, was ich mir gewünscht habe! :-) -- ^Thomas 13:08, 2. Jun. 2017 (CEST)

@Speravir, Reise Reise:, danke auch von mir! @Z thomas:, wäre der Wunsch damit für dich erledigt? Dann würde ich ihn umziehen nach Wikipedia:Umfragen/Technische_Wünsche_2017/Bereits_umgesetzte_Wünsche. Wenn nicht, könntest du oben ergänzen, was dir noch fehlt? -- Beste Grüße, Johanna Strodt (WMDE) (Diskussion) 14:25, 7. Jun. 2017 (CEST)

Einspruch, Johanna. Es fehlt Stabilität. Ein Tool auf wmflabs ist ... ein Tool. Und keine dauerhafte Lösung. Und diese wird nach meinem Verständnis der technicshen Wünsche gesucht. — Raymond ^Disk. 15:16, 7. Jun. 2017 (CEST)

Danke, Raymond. Absolut nachvollziehbar. Hintergrund meiner Frage war, dass einige Vorschlagende in dieser Umfrage schon sehr zufrieden mit der Lösung durch Tools waren. Weil die Diskussion bei jedem Wunsch mit Beginn der Abstimmung (19. Juni) ausgeblendet wird, wäre es gut, die Erkenntnisse aus der Diskussion (u. a. den Hinweis in deinem Einspruch) in die Problembeschreibung mit aufzunehmen. Damit wir den Wunsch von Z thomas nicht verfälschen, wäre es ideal, wenn er das machen würde. @Z thomas: :)-- Beste Grüße, Johanna Strodt (WMDE) (Diskussion) 15:41, 7. Jun. 2017 (CEST)

@Raymond, Johanna Strodt (WMDE): ich hab das Tool GLAMorous unter Anmerkungen erwähnt. ok so? -- ^Thomas 15:55, 7. Jun. 2017 (CEST)

@Z thomas: So gut wie! Ich kann mir vorstellen, dass einige Lesende sich fragen, was genau dein Wunsch ist, obwohl mindestens ein Tool die Funktion schon bietet. Darum könntest du als letzten Satz bei „Anmerkungen“ noch ergänzen, dass du eine dauerhafte / integrierte Lösung suchst und eben kein Tool. In schönerer Formulierung. ;) -- Beste Grüße, Johanna Strodt (WMDE) (Diskussion) 18:44, 8. Jun. 2017 (CEST)

@Johanna Strodt (WMDE): so, etwas klargestellt. gruß -- ^Thomas 11:32, 9. Jun. 2017 (CEST)

Unterstützung

1.  Pro Z thomas (Einreichende Person)
2.  Pro --ManfredK (Diskussion) 16:30, 20. Jun. 2017 (CEST)
3.  Pro -jkb- 13:59, 21. Jun. 2017 (CEST)
4.  Pro -- Michi 19:39, 21. Jun. 2017 (CEST)
5.  Kontra Es gibt bereits GLAMorous, was genau das kann. Das muss nicht in die MediaWiki Software. -- Freddy2001 ^DISK 12:17, 24. Jun. 2017 (CEST)
6.  Pro --Thomas Obermair 4 (Diskussion) 17:09, 28. Jun. 2017 (CEST)
7.  Pro Und dazu am besten noch Benachrichtigungen bei neuen Benutzungen. --Fixuture (Diskussion) 21:33, 1. Jul. 2017 (CEST)
   
   

Nachricht oder Anzeige, wenn in beobachteten Artikeln verwendete Bilder in Commons zur Löschung vorgeschlagen werden

Was ist das Problem?

Wenn in beobachteten Artikeln Bilder auf Commons gelöscht werden, bekommt man es erst durch die tatsächliche Löschung mit (da die damit verbundene Artikeländerung in der Beobachtungsliste erscheint). Für eine Teilnahme an der Löschdiskussion ist es dann zu spät, ebenso wie beispielsweise für eine Reparatur des Problems auf Commons (z.B. dem nachträglichen Besorgen der commons-verträglichen Lizenz) oder dem Suchen nach einem (tatsächlich und nicht nur dem Gedächtnis nach vermutet) ähnlichen Bild.

Wen betrifft das Problem besonders?

Alle Wikipedia-Autoren, die sich um die Bebilderung von Artikeln kümmern.

Lösungsvorschlag

Wenn für ein in einem Artikel der Beobachtungsliste verwendetes Bild auf Commons eine Löschdiskussion eingeleitet wird, entweder eine Nachricht erzeugen, oder den Artikel in der Beobachtungsliste (wie ansonsten bei einer Änderung des Artikels selbst) mit einem entsprechenden Vermerk aufscheinen lassen, oder (ergänzt nach Hinweis in der Diskussion) auf der Diskussionsseite des Artikels eine Nachricht erzeugen (möglicherweise ähnlich dem derzeit inaktiven CommonsNotificationBot der englischen Wikipedia).

Vorschlagende Person

Karl432 (Diskussion) 19:45, 1. Jun. 2017 (CEST)

Diskussion

@Karl432: Es gibt in der en.WP den CommonsNotificationBot. Der ist schon seit Juni 2012 inaktiv (seit November 2015 wird vermeldet: "may be re-written soon") Der hat damals auf der Diskussionsseite eines Artikels darauf hingewiesen, wenn eines der eingebunden Bilder einen Löschantrag erhielt: Notification of possible deletion of File:Ian Fleming signature.svg. -- Reise Reise (Diskussion) 10:25, 2. Jun. 2017 (CEST)

Danke für den Hinweis, ich habe diese Möglichkeit jetzt in meinem Lösungsvorschlag ergänzt. -- Karl432 (Diskussion) 10:48, 2. Jun. 2017 (CEST)

In der fr.wp gibt es den aktiven NaggoBot. Hystrix (Diskussion) 00:32, 22. Jun. 2017 (CEST)

Siehe auch phab:T167614 --El Grafo _(COM) 08:45, 23. Jun. 2017 (CEST)

Unterstützung

1.  Pro Karl432 (Einreichende Person)
2.  Pro -- ^Thomas 13:43, 20. Jun. 2017 (CEST)
3.  Pro --Stepro (Diskussion) 18:18, 20. Jun. 2017 (CEST)
4.  Pro Hystrix (Diskussion) 22:33, 20. Jun. 2017 (CEST)
5.  Pro --Avron (Diskussion) 19:12, 21. Jun. 2017 (CEST)
6.  Pro --El Grafo _(COM) 08:45, 23. Jun. 2017 (CEST)
7.  Pro --Klaus Eifert (Diskussion) 00:37, 26. Jun. 2017 (CEST)
8.  Pro --Thomas Obermair 4 (Diskussion) 17:10, 28. Jun. 2017 (CEST)
9.  Pro --Sebastian Wallroth 09:11, 1. Jul. 2017 (CEST)
10.  Pro -- Mboesch (Diskussion) 11:48, 1. Jul. 2017 (CEST)
11.  Pro --Fixuture (Diskussion) 21:37, 1. Jul. 2017 (CEST)
12.  Pro —DerHexer (Disk., Bew.) 22:54, 1. Jul. 2017 (CEST)
13.  Pro --C₂₁H₂₂N₂O₂ (Diskussion) 22:27, 2. Jul. 2017 (CEST)
14.  Pro --Zaccarias (Diskussion) 19:33, 2. Jul. 2017 (CEST)
15.  Pro -- X:: black ::X (Diskussion) 23:02, 2. Jul. 2017 (CEST)
    
    

Wikisource: Die dort angebotene Funktion zur EPUB-Erstellung (Tool: WSExport) endlich zum Funktionieren bringen.

Was ist das Problem?

In der deutschsprachigen Wikisource wird auf der linken Seite unter „Drucken / Exportieren“ die Funktion „Download als EPUB“ angeboten. Dies erfolgt dann letztlich über die Anwendung „WSExport“. Damit sollte es eigentlich möglich sein, die Texte aus Wikisource ins EPUB-Format zu konvertieren, damit sie auf viele gängige eReader geladen und dort gelesen werden können. Seit Längerem (oder sogar von Anfang an?) funktioniert das aber leider nicht. Die konvertierten Dateien können auf dem gängigen Reader „Tolino“ und wohl auch auf anderen Readern nicht korrekt dargestellt werden.

Die Ursache liegt – soweit ich das verstanden habe – wohl in der in der deutschen Wikisource verwendeten Vorlage „BlockSatzStart“, die meines Wissens eine saubere Wiedergabe am Bildschirm ermöglichen soll. Sie führt aber wohl auch zu den unbrauchbaren EPUB-Konvertierungen. (Wird so etwas eigentlich nicht gestestet, bevor es implementiert wird?)

Eine Diskussion hierzu ist hier zu finden: s:Wikisource:Skriptorium#Vorlage:BlockSatzStart.

Wen betrifft das Problem besonders?

Das Problem betrifft im Prinzip jeden Menschen, der sich einen der Texte der deutschen Wikisource ohne Umstände auf seinen EPUB-Reader laden und ihn dort bequem lesen möchte.

Lösungsvorschlag

Ich bin leider nicht besonders versiert in der HTML-Programmierung. Den aktiven Wikisourcianern ist offenbar bisher auch noch keine wirkliche Lösung eingefallen. Als Laie frage ich mich allerdings, ob man im Zuge des Konvertierungsvorgangs nicht zuerst die Wirkung der Vorlage BlockSatzStart eliminieren könnte und dann danach die Textkonvertierung durchführen. Oder eben auf eine andere Weise sicherstellen, dass die Konvertierung valide Ergebnisse liefert. Das sollte doch eigentlich kein Ding der Unmöglichkeit darstellen!?

Anmerkungen

Das Ziel, die Texte einer breiten Öffentlichkeit zugänglich zu machen, wird damit m.E. an einer wichtigen Stelle stark eingeschränkt. Es mindert die Nutzbarkeit der deutschen Wikisource, damit auch ihren Bekanntheitsgrad und möglicherweise geht der WS auch der eine oder andere Mitarbeiter verloren, der sonst hätte gewonnen werden können.

Vorschlagende Person

Unendlicheweiten (Dialog) 00:00, 9. Jun. 2017 (CEST)

Diskussion

Die korrekte Verbreitung unserer Texte über alle möglichen Kanäle ist ein Kernanliegen unseres Projektes, nur so bekommt das Ganze seine verdiente Breitenwirkung. Damit bekommen wir vielleicht auch zusätzlich die dringend benötigten Bearbeiter und so tut sich damit eine gute Rückwirkung auf WS auf. --A. Wagner (Diskussion) 22:13, 10. Jun. 2017 (CEST)

Unterstützung

1.  Pro Unendlicheweiten (Einreichende Person)
2.  Pro Zabia (Diskussion) 17:33, 20. Jun. 2017 (CEST)
3.  Pro Carsten (Diskussion) 17:50, 20. Jun. 2017 (CEST)
4.  Pro Paulis 19:55, 20. Jun. 2017 (CEST)
5.  Pro A. Wagner (Diskussion) 21:42, 20. Jun. 2017 (CEST)
6.  Pro Dorades (Diskussion) 21:56, 20. Jun. 2017 (CEST)
7.  Pro Hermannh (Diskussion) 21:58, 20. Jun. 2017 (CEST)
8.  Pro --Trockennasenaffe (Diskussion) 09:31, 21. Jun. 2017 (CEST)
9.  Pro Conny 13:55, 21. Jun. 2017 (CEST).
10.  Pro 9xl (Diskussion) 10:21, 22. Jun. 2017 (CEST)
11.  Pro --Guglhupfner (Diskussion) 11:51, 22. Jun. 2017 (CEST)
12.  Pro --GodeNehler (Diskussion) 23:13, 22. Jun. 2017 (CEST)
13.  Pro --Sinuhe20 (Diskussion) 17:52, 23. Jun. 2017 (CEST)
14.  Pro BB3 (Diskussion) 08:41, 25. Jun. 2017 (CEST)
15.  Pro --DianeAnna (Diskussion) 22:05, 25. Jun. 2017 (CEST)
16.  Pro — Raymond ^Disk. 17:15, 26. Jun. 2017 (CEST) Siehe aber auch Phab:T97672 für eine in MediaWiki integrierte Lösung.
17.  Pro --Thomas Obermair 4 (Diskussion) 17:12, 28. Jun. 2017 (CEST)
18.  Pro --Έλβις λεβτ (Diskussion) 10:06, 29. Jun. 2017 (CEST)
19.  Pro --Sebastian Wallroth 09:12, 1. Jul. 2017 (CEST)
20.  Pro —DerHexer (Disk., Bew.) 22:54, 1. Jul. 2017 (CEST)
21.  Pro -- X:: black ::X (Diskussion) 23:11, 2. Jul. 2017 (CEST)
    
    

Commons: Sortierung der Bilder in den Kategorien

Was ist das Problem?

Die Bilder werden in den Kategorien standardmäßig alphabetisch nach dem Bildnamen sortiert.

Wen betrifft das Problem besonders?

Das betrifft alle Nutzer.

Lösungsvorschlag

Die Sortierung der Bilder in den Kategorien optional umstellen. Nicht mehr nach dem Namen einer Datei sortieren, sondern nach dem Datum der Einstellung in Commons. Die zuletzt hochgeladenen Bilder an den Anfang der Kategorie stellen.

Eine vielleicht ebenso sinnvolle Option wäre, das Datum der Aufnahme zum Sortieren zu verwenden.

Anmerkungen

Mit der Sortierung nach Datum sind neue (gute) Bilder schneller in großen Dateien zu finden. Außerdem sind die Bilder von besonders tüchtigen Usern, die ihre Bildnamen mit kleinen Zahlen beginnen, nicht die dauerhaft ersten Bilder einer Kategorie. Eine zusätzliche Schwierigkeit stellt sicherlich die auch häufig genutzte Möglichkeit dar, die Sortierungsreihenfolge durch Sortierschlüssel zu beeinflussen, und zwar sowohl per {{DEFAULTSORT:}} für alle Kategorien, in die ein Bild einsortiert wurde, als auch individuell für eine Kategorie mit [[Category:$Category|$Sortkey]], wobei letzteres einen allgemeinen Sortierschlüssel überschreibt.

PS: Neben der Sortierung der Bilder ist eine verbesserte Navigation unabdingbar wichtig. Nicht nur vorhergehende Seite / nächste Seite. Unsere Kategorien werden derzeit von Panoramiouploads überschwemmt. Niemand klickt sich selbst bei individualisierter Sortierung z. B. 15x (!) durch 3129 Dateien in c:Category:Blasewitz. Sinnvolle Navigation: << . < . 1 . 2 . 3 . ... . Gehe zu Seite ZZ . > . >>, analog Navigation z. B. DNB unten --Frze> ^{> Disk} 12:01, 30. Jun. 2017 (CEST)

Vorschlagende Person

Orchi (Diskussion) 20:10, 9. Jun. 2017 (CEST)

Diskussion

Es sollten mehrere Sortieroptionen alternativ zur Verfügung stehen, die alphabetische muss dabei erhalten bleiben. Neben dem Uploaddatum ist auch das Aufnahmedatum ein sinnvolles Sortierkriterium. --Sitacuisses (Diskussion) 23:25, 9. Jun. 2017 (CEST)

Auch hat Orchi hat vergessen, dass die Sortierung nach Name durch Sortierschlüssel übersteuert sein kann. Da müsste in jedem Fall berücksichtigt werden. Orchi, du solltest alle unsere Hinweise in die Anmerkungen aufnehmen, da die Diskussion in wenigen Tagen ausgeblendet wird. — Speravir – 23:47, 9. Jun. 2017 (CEST)

Nach Anfrage von Orchi auf meiner Diskussionsseite habe ich die Anmerkungen von Sitacuisses und mir oben eingearbeitet, vgl Spezial:Diff/166265270/166266411. — Speravir – 20:32, 10. Jun. 2017 (CEST)

Für Nachnutzer ist auch die Dateigröße als Sortierkriterium interessant. --Sebastian Wallroth 09:14, 1. Jul. 2017 (CEST)

Unterstützung

1.  Pro Orchi (Einreichende Person)
2.  Pro -- Marcus Cyron Reden 10:36, 19. Jun. 2017 (CEST) -- allerdings nicht für eine grundsätzliche Änderung, sondern für eine Wahlmöglichkeit zwischen den Varianten, da in den meisten Fällen das Alphabet doch der sinnvollere Ordner ist
3.  Pro für die optionale Variante --MB-one (Diskussion) 17:57, 19. Jun. 2017 (CEST)
4.  Pro für die optionale variante mit weiteren Parametern wie Größe, Aufnahmedatum, Uploadedatum, Uploder -- ^Thomas 13:45, 20. Jun. 2017 (CEST)
5.  Pro --HerrAdams (D) 18:51, 20. Jun. 2017 (CEST)
6.  Pro Das sollte allerdings noch wesentlich flexibler sein und vielleicht bei Bedarf auch vom Anwender interaktiv wählbar sein. --XRay ^Disk. 13:54, 21. Jun. 2017 (CEST)
7.  Pro Für eine wählbare Sorierung. --Magnus (Diskussion) 16:08, 22. Jun. 2017 (CEST)
8.  Pro Guter Ansatz, löst aber das eigentliche Problem nicht, dass in den Kategoien viel zu viele schlechte Bilder gelistet sind! -- Maesi64 (Diskussion) 22:35, 23. Jun. 2017 (CEST)
9.  Pro --Atamari (Diskussion) 22:53, 23. Jun. 2017 (CEST)
10.  Pro --Thomas Obermair 4 (Diskussion) 17:12, 28. Jun. 2017 (CEST)
11.  Pro --Frze> ^{> Disk} 11:53, 30. Jun. 2017 (CEST)
12.  Pro --Sebastian Wallroth 09:14, 1. Jul. 2017 (CEST)
13.  Pro Für mehr Sortierungsoptionen von Commons Bildern inklusive des Einstellungs- und Aufnahmedatums, Anzahl der Benutzungen in Artikeln, Bildgröße etc. --Fixuture (Diskussion) 21:39, 1. Jul. 2017 (CEST)
14.  Pro —DerHexer (Disk., Bew.) 22:55, 1. Jul. 2017 (CEST)
15.  Pro --Sitacuisses (Diskussion) 14:59, 2. Jul. 2017 (CEST)
16.  Pro für wählbare Sortierungsoptionen. --Zaccarias (Diskussion) 19:51, 2. Jul. 2017 (CEST)
17.  Pro --ProloSozz (Diskussion) 23:17, 2. Jul. 2017 (CEST)
18.  Pro für eine Realisierung als Option, möglichst mit noch weiteren Parametern wie Aufnahmedatum, Größe, Uploder. -- X:: black ::X (Diskussion) 23:20, 2. Jul. 2017 (CEST)
    
    

Upload Wizard soll sich meinen Namen merken

Was ist das Problem?

Wen ich eigene Bilder auf Wikimedia Commons mit dem Standart-Hochlade-Assistenten (Upload-Wizard) hochlade, wähle ich dort "Diese Datei ist meine eigene Arbeit" und trage dann in das entsprechende Feld meinen Namen ein. Standard-mäßig steht dort mein Nutzername, doch ich will meinen echten, vollen Namen nutzen. Das Formular merkt sich dies nicht und ich muss meinen Namen jedes mal wieder eintragen.

Wen betrifft das Problem besonders?

Leute die selbst gemachte Bilder mit dem Upload-Wizzard hochladen und auf ordentliche Namensnennung wert legen.

Lösungsvorschlag

Mein Name ändert sich nicht so oft – also sollte sich der Upload-Wizzard den Inhalt des Feldes merken. (Client- oder Serverseitig ist egal)

Vorschlagende Person

Michi 21:00, 9. Jun. 2017 (CEST)

Diskussion

Siehe Task T154154: Upload Wizard: Remember uploader name und allgemeiner Task T40026: Add user preferences for some fields. — Raymond ^Disk. 21:19, 9. Jun. 2017 (CEST)

Unterstützung

1.  Pro MichaelSchoenitzer (Einreichende Person)
2.  Pro --FNDE 12:02, 20. Jun. 2017 (CEST)
3.  Pro -- ^Thomas 13:47, 20. Jun. 2017 (CEST)
4.  Pro --Thomas Obermair 4 (Diskussion) 17:13, 28. Jun. 2017 (CEST)
5.  Pro --ProloSozz (Diskussion) 23:18, 2. Jul. 2017 (CEST)
   
   

Bildfilter für die Kartenebene „Commons on OSM“ anbieten: wartungsbedürftige/gute/aktuelle Bilder hervorheben

Was ist das Problem?

A.) Derzeit werden hunderttausende geokodierte Bilddateien von Panoramio nach Commons hochgeladen. Wegen der Unzulänglichkeit der automatischen Kategorisierung landen sie unter der Wartungskategorie c:Category:Media needing categories und sind damit auf dem üblichen Weg kaum aufzufinden und zu nutzen. Zuvor wurden viele Tausend Bilder mit fragwürdigen automatisch gewählten Kategorien und c:Category:Media needing category review versehen. Aufgrund der Geokoordinaten werden die Bilder auf der OpenStreetMap-Kartenebene Commons on OSM an ihrem Aufnahmeort angezeigt. Damit bietet sich die Karte als hervorragendes Hilfsmittel für die Einordnung in lokale Kategorien an. Doch sind auf der Karte die unkategorisierten oder zu überprüfenden Bilder leider nicht von bereits richtig eingeordneten zu unterscheiden. Um dort Dateien mit Wartungsbedarf zu finden, muss man daher immer wieder unnötig viele Bilder einzeln anklicken und aufrufen; ob ein Bild schon überprüft wurde ist nicht erkennbar.

B.) Eine weitere Problemstellung wäre etwa die Auswahl guter Bilder eines Ortes über die Karte. Das wird mit der Zeit immer relevanter, je mehr Bilder am gleichen Ort vorhanden sind, deren Symbole sich auf der Karte überlagern.

Wen betrifft das Problem besonders?

A.) Commons-Bearbeiter, die fehlende und falsche Kategorisierung korrigieren.

B.) Nutzer der Karte „Commons on OSM“, denen dort eine Bildauswahl nach eigenen Vorgaben ermöglicht wird.

Lösungsvorschlag

A.) Dateien unterhalb von c:Category:Media needing categories und c:Category:Media needing category review sollten in „Commons on OSM“ besonders hervorgehoben werden, etwa mit einem eigenen Icon; zum Beispiel das bei anderen Bildern angezeigte Commons-Logo in Graustufen umgewandelt. Eine andere Möglichkeit wäre eine Umschaltfunktion, die wahlweise a.) die wartungsbedürftigen oder b.) die fertig kategorisierten Bilder ausschaltet oder c.) alle auf der Karte anzeigt.

B.) Weitere Filter könnten nur exzellente oder Qualitätsbilder anzeigen und so die Bildauswahl erleichtern. Auch eine Filterung nach Alter des Bildes wäre denkbar.

Der vordringliche Punkt meines Vorschlags ist jedoch die Wartungserleichterung angesichts der wachsenden Menge nicht oder falsch kategorisierter Dateien.

Vorschlagende Person

Sitacuisses (Diskussion) 23:51, 9. Jun. 2017 (CEST)

Diskussion

Unterstützung

1.  Pro Sitacuisses (Einreichende Person)
2.  Pro -- ^Thomas 13:49, 20. Jun. 2017 (CEST)
3.  Pro Hermannh (Diskussion) 21:58, 20. Jun. 2017 (CEST)
4.  Pro --Thomas Obermair 4 (Diskussion) 17:13, 28. Jun. 2017 (CEST)
5.  Pro --Sebastian Wallroth 09:15, 1. Jul. 2017 (CEST)
6.  Pro, unter der Voraussetzung, dass die Unterscheidung in Form einer individuell aktivierbaren (Opt-In) Filterung erfolgt, da die Karte sich ja in erster Linie für „Leser“ die Bilder suchen da ist, nicht für das „Wartungspersonal“). -- X:: black ::X (Diskussion) 23:28, 2. Jul. 2017 (CEST)
   
   

Commons: Bildersuche und -auswahl vereinfachen (Bilder in Gruppen ähnlich wie bei flickr)

Was ist das Problem?

Als Autorin suche ich auf Commons Bilder, um Metathemen wie Spielentwicklung oder Community Building zu bebildern. Zu diesen Themen werde ich selten fündig, weil

• sich keine Gruppen einrichten lassen
• die Tags nicht ausreichen, um visuell auszuwählen (inhaltliches Problem)
• die themenbezogene Auswahl eher wissenachaftlich als illustierend ist
• Commons kaum verwendet wird für Bildarchivierung.

Ich weiche dann auf andere Bildarchive aus.

Wen betrifft das Problem besonders?

Zielgruppe sind Communities sowie Teamprojekte, die Bilder brauchen.

Lösungsvorschlag

Tags vereinfachen und für Gruppenbildung aufbereiten. Suchfunktion verbessern.

• visuelle Suche in Gruppen ermöglichen
• Tags ausweiten, intuitivere Oberfläche schaffen
• Communs für Archivierung bereit stellen.
• Bilduchfunktionen verbessern, Sortierung und Auswahl erleichtern
  Anmerkungen

Mit thumbs arbeiten, um auf der visuellen Ebene zu bleiben.

Vorschlagende Person

Medea7 (Diskussion) 13:30, 10. Jun. 2017 (CEST)

Diskussion

@Medea7: Besten Dank für den Wunsch! Die erste Einschätzung vom Team Technische Wünsche zu deinem Wunsch ist, dass er noch zu umfassend ist, als dass wir ihn im Rahmen des Projekts „Technische Wünsche“ bearbeiten könnten. Wenn der Wunsch so umfangreich bleibt wie er jetzt ist, müssten wir ihn leider nach Wikipedia:Umfragen/Technische_Wünsche_2017/Wünsche_außerhalb_des_Projektrahmens verschieben. Darum schau doch mal, was in dem großen Themenfeld „Bildersuche und -auswahl vereinfachen“ für ein ganz konkreter, einzelner Wunsch steckt, der die Situation auch schon verbessern würde. Beispiele, was vom Umfang her passen könnte (wobei man auch diese Möglichkeiten später noch auf ihre Machbarkeit hin prüfen müsste):

• eine dezidierte Bildersuche mit auf Bilder zugeschnittenen Suchergebnisseiten, inkl. Vorschaubildern, bildspezifischen Metadaten etc.
• eine Möglichkeit, interne Kollektionen anzulegen, in denen man Bilder für sich selbst sammeln, ohne „offizielle“ Kategorien anzulegen.

Wenn du einen konkreten Wunsch findest, solltest du ihn etwas ausformulieren und auch den Wunschtitel noch entsprechend anpassen. Die Abstimmung beginnt am 19. Juni, bis dahin kannst du also noch umformulieren. Wenn du noch Fragen hast, wäre es aber gut, wenn du sie heute im Laufe des Tages noch stellen könntest.

Mittelfristig wird sich übrigens die Suche nach Bildern durch das Projekt Strukturierte Daten auf Commons massiv verbessern. Das Projekt befindet sich zzt. in Entwicklung, ist allerdings ein Riesenprojekt für ein mehrköpfiges Team und mehrere Jahre – das wird also auf jeden Fall noch dauern. -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 13:10, 16. Jun. 2017 (CEST)

Unterstützung

1.  Pro Medea7 (Einreichende Person)
2.  Pro --Thomas Obermair 4 (Diskussion) 17:14, 28. Jun. 2017 (CEST)
3.  Neutral Dafür gibt es ja die Kategorien. (Gruppen=Kategorien) Häufig fehlen Kategorien, was heißt, dass man sie erstellen sollte. Außerdem kann Kategorienintersektion hilfreich sein.  Pro Verbesserungen der Bilder-suche, -sortierung und -auswahl. --Fixuture (Diskussion) 21:43, 1. Jul. 2017 (CEST)
   
   

Darstellung von sphärischen Panoramas in Wikipedia

Was ist das Problem?

Hässlich in 2D, cool und sehr dokumentarisch in 3D (siehe hier).

Das Problem ist, dass es recht coole sphärische Panoramas (vollständige Kugelsichten aus dem zentralen Gesichtspunkt) in Commons gibt (anbei eine Kategorie mit ein paar Beispielen), die viele Objekte (insb. Innenräume) am besten dokumentieren und darstellen. In Wikipedia gibt es aber keine Möglichkeit diese Bilder bequem und unkompliziert einzubinden.

Wen betrifft das Problem besonders?

Leser der Enzyklopäedie

Lösungsvorschlag

Als Basis könnte man das Panoviewer (siehe Beispiel hier), ein Tool von Dschwen und auf Basis von Pannellum

Vorschlagende Person

Poco a poco (Diskussion) 13:34, 10. Jun. 2017 (CEST)

Diskussion

Bin ich auch für. Mir wäre dann auch noch wichtig das man die Bilder mit dem Player in VR betrachten kann. --Noobius2 (Diskussion)

Unterstützung

1.  Pro Poco a poco (Einreichende Person)
2.  Pro  _hugarheimur 08:13, 20. Jun. 2017 (CEST)
3.  Pro --FNDE 12:04, 20. Jun. 2017 (CEST)
4.  Pro -- ^Thomas 13:46, 20. Jun. 2017 (CEST)
5.  Pro DCB (Diskussion • Bewertung) 15:36, 20. Jun. 2017 (CEST)
6.  Pro Zabia (Diskussion) 17:35, 20. Jun. 2017 (CEST)
7.  Pro --Andropov (Diskussion) 17:55, 20. Jun. 2017 (CEST)
8.  Pro // Martin K. (Diskussion) 18:15, 20. Jun. 2017 (CEST) / Gerne auch im Rahmen der generellen Einbindung interaktiver Medieninhalte
9.  Pro --Claell (Diskussion) 19:27, 20. Jun. 2017 (CEST)
10.  Pro --Trockennasenaffe (Diskussion) 09:31, 21. Jun. 2017 (CEST)
11.  Pro -- Michi 19:39, 21. Jun. 2017 (CEST)
12.  Pro --MGChecker – (📞| 📝| ) 20:45, 21. Jun. 2017 (CEST)
13.  Pro --Jossi (Diskussion) 13:53, 22. Jun. 2017 (CEST)
14.  Pro --GodeNehler (Diskussion) 23:14, 22. Jun. 2017 (CEST)
15.  Pro idealerweise auch für 360° Videos --El Grafo _(COM) 08:49, 23. Jun. 2017 (CEST)
16.  Pro --Daniel749 Disk. (ST–WPST) 22:10, 23. Jun. 2017 (CEST)
17.  Pro --Nichtich (Diskussion) 22:30, 23. Jun. 2017 (CEST)
18.  Pro -- Freddy2001 ^DISK 12:18, 24. Jun. 2017 (CEST)
19.  Pro --DianeAnna (Diskussion) 22:03, 25. Jun. 2017 (CEST)
20.  Pro --Noobius2 (Diskussion)
21.  Pro --Thomas Obermair 4 (Diskussion) 17:14, 28. Jun. 2017 (CEST)
22.  Pro --Kolossos 20:57, 29. Jun. 2017 (CEST)
23.  Pro --Schönitzer (Diskussion) 20:55, 30. Jun. 2017 (CEST)
24.  Pro --Sebastian Wallroth 09:15, 1. Jul. 2017 (CEST)
25.  Pro Die Art der Einbindung wurde allerdings noch nicht erläutert. Da gibt es viele Möglichkeiten. zum Beispiel könnte man derartige Panoramas auf Klick (worauf?) in einem neuen Tab öffnen oder im Artikel eingebettet aufspannen. Falls ein 2D Bild eingebettet wird, auf das man klicken kann, so könnte man ja bloß einen bestimmten (spezifizierbaren?) Teil des Panoramas anzeigen, so dass es gut aussieht. Man könnte es ähnlich wie diese ProveIt-Bar zB unten am Bildschirm anzeigen (und eventuell das Panorama per Sektion ändern). Da sind mehr Ideen, Vorschläge, Konsultation, Designs und Konzepte gefragt. Bestimmt auch relevant bezüglich VR und der App. --Fixuture (Diskussion) 21:51, 1. Jul. 2017 (CEST)
26.  Pro —DerHexer (Disk., Bew.) 22:58, 1. Jul. 2017 (CEST)
27.  Pro -- Mr N (Diskussion) 23:14, 2. Jul. 2017 (CEST) Wäre echt schön, wenn man das in Artikel einbinden könnte. Falls jemand (Java-)Skripte deaktiviert haben sollte, sollte er/ sie aber weiterhin das einfache 2D-Bild angezeigt bekommen. @2DragonFreak: bestimmt interessiert dies auch dich.
    
    

Verbesserung von OCR für Frakturschrift

Was ist das Problem?

Dieses Problem betrifft vor allem das Schwesterprojekt Wikisource. Ein Schwerpunkt der Arbeit von Wikisource ist die Transkiption von historischen Texten auf der Basis gescannter oder abfotografierter Textseiten (Scans) in e-Text und dessen Publikation im Internet. Diese Texte stehen dann für die Allgemeinheit kostenlos zur Verfügung und können auch nicht zuletzt zur Verbesserung der Quellenlage für die Wikipedia genutzt werden. Die Basis für eine rationelle Erstellung von e-Texten sind die mit einem Texterkennungsprogramm (OCR[optical character recognition]-Programm) erstellten Rohtexte, die dann noch von Hand fertig korrigiert und formatiert werden müssen. Für normale gerundete Schrift (Antiqua) ist das kein Problem, hier sind genügend freie Programme auf dem Markt. Das Problem stellt die Texterkennung von gebrochenen Schriften (Fraktur) dar.

Das Problem kann schon dadurch entschärft werden, dass der Zugang zu vorhandenen OCR-Lösungen online erleichtert wird. Wie bei jeder Arbeit so ist auch für die Transkribtionsarbeit in Wikisource der Zeitfaktor entscheidend. Was schaffe ich in der mir zur Verfügung stehenden Zeit? Kann ich überhaupt meine Ziele erreichen, wo doch nur die knappe Freizeit dafür zur Verfügung steht? Eine Möglichkeit, Scanpakete mit 100 oder mehr Scans hochzuladen und dann den Text en bloc herunterzuladen, wäre dazu ein erster Schritt. Für die weitere Korrektur können dann ggf. automatisierte Möglichkeiten in Textprogrammen (z. B. Ersatz von Zeichen) offline genutzt werden.

Wen betrifft das Problem besonders?

Das Problem betrifft schwerpunktmäßig das Projekt Wikisource, siehe s:de:Wikisource:OCR. Hier steht eine Lösung im Rahmen der Korrektur im PR2-Modus zur Verfügung, mit der aber nur einzelne Seiten mit einigem zeitlichen Aufwand und in mäßiger Qualität bearbeitet werden können. Beispiel: bitte OCR-Button für Fraktur drücken und warten

Lösungsvorschlag

Vereinfachung des Zugangs und Verbesserung der Leistung dieser schon vorhandenen Lösung. Das Ganze sollte natürlich internetbasiert sein, mit einer Möglichkeit zum Hochladen ganzer Scanpakete und zum Download der Texte.

Anmerkungen

Das Ganze ist sicher nur mit hohem Aufwand zu realisieren, würde aber für die Wikisource-Communitiy eine erhebliche Erleichterung darstellen.

Vorschlagende Person

A. Wagner (Diskussion) 19:36, 10. Jun. 2017 (CEST)

Diskussion

@A. Wagner: Kannst du die Erleichterung für die Autoren durch eine neue Software beschreiben? Derzeit kann ich ja auf Klick eine Seite bekommen, Korrektur muss ich diese ja lesen. Was würde es bringen, wenn man mit einem Rutsch viele Seiten umwandeln könnte? Dankend, Conny 20:43, 10. Jun. 2017 (CEST).

So wie ich es jetzt als Laie sehe, wäre eine verbesserte Erkennung und der „Übersetzung“ der Zeichen wünschenswert? Conny 20:45, 10. Jun. 2017 (CEST).

Ich antworte schon mal (bitte korrigiert mich bzw. ergänzt das noch, falls sinnvoll): es stellt einen immensen Arbeitsaufwand dar, wenn man für jede Seite einzeln die OCR-Funktion aufrufen muss und dann bei jeder Seite auch warten muss, bis das fertig ist. Dann muss erst zur nächsten Seite gewechselt werden, dann dort wieder die OCR-Funktion betätigt werden, usw. Wenn man dagegen alle Seiten im Block bearbeiten könnte, können die per Bot eingespielt werden. Das wäre eine enorme Zeitersparnis! Es handelt sich dabei um einen der Kernprozesse der WS! Deshalb unterstütze ich den Wunsch von A. Wagner leidenschaftlich.

Und ja - natürlich - je besser die Texterkennung dann auch funktioniert, das heisst, je mehr Zeichen korrekt erkannt werden, desto besser und zeitsparender wäre es natürlich für die Arbeit in WS! --Unendlicheweiten (Dialog) 21:51, 10. Jun. 2017 (CEST)

Schließe mich dieser Ausführung an! --A. Wagner (Diskussion) 22:03, 10. Jun. 2017 (CEST)

Mit welcher Texterkennung ist eigentlich die fast sagenhaft präzise Transskription bei s:Index:Sylvicultura oeconomica.pdf möglich gewesen - oder steckt da viel händische Zutat drin? Wenn DAS von 'nem Automaten stammt, wäre dies wohl die Lösung vieler Probleme. --Hvs50 (Diskussion) 22:05, 10. Jun. 2017 (CEST)

Habe einen Hinweis auf OCRopus gefunden. Conny 14:02, 12. Jun. 2017 (CEST).

Korrekt. Im Bereich Texterkennung für historische Texte (Drucke vor 1900) ist OCRopus immer noch state of the art. Eine Kostprobe der Erkennung ohne jede Nachbearbeitung zeigt: Sylvicultura_oeconomica.pdf/49. In der Quelltextansicht gewinnt man einen guten Eindruck, was damit erreichbar ist. Das halbautomatische Postprocessing habe ich dann mit regex fürs Grobe und einem aus dem Text selbst gewonnen hunspell-Wörterbuch vorgenommen. Das Erkennungsmodell muß man allerdings selbst für jeden einzelnen Druck neu entwickeln. Für nicht so alte Texte gibt es hingegen ein gutes allgemeines Frakturmodell.--93.131.250.39 15:11, 14. Jun. 2017 (CEST)

@A. Wagner: Danke für den Wunsch! Das Team Technische Wünsche schließt eine Verbesserung für die Verarbeitung von Frakturschrift aus technischen Gründen nicht von vornherein aus. Ob eine Lösung aber in einer verbesserten OCR-Software liegen würde oder in der Verbesserung der Schritte drumherum (z. B. Seiten en bloc bearbeiten), können wir zum jetzigen Zeitpunkt noch nicht sagen. Um beide Optionen offen zu halten, wäre es gut, wenn du unter „Was ist das Problem?“ aus der Diskussion noch ergänzen könntest, inwiefern auch eine Verbesserung des Prozesses rund um die eigentliche OCR-Software schon eine Lösung für das Problem wäre. All das oben Gesagte ist allerdings noch kein Garant, dass sich nicht später doch noch technische Blocker auftun – und natürlich müsste es der Wunsch auch in die Topliste schaffen. -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 18:53, 16. Jun. 2017 (CEST)

Done, siehe oben. Für weitere Erläuterungen stehe ich gerne zur Verfügung. --A. Wagner (Diskussion) 09:48, 17. Jun. 2017 (CEST)

Unterstützung

1.  Pro A. Wagner (Einreichende Person)
2.  Pro Jeb (Diskussion) 20:28, 19. Jun. 2017 (CEST)
3.  Pro --Unendlicheweiten (Dialog) 23:24, 19. Jun. 2017 (CEST)
4.  Pro Conny 14:43, 20. Jun. 2017 (CEST).
5.  Pro DCB (Diskussion • Bewertung) 15:37, 20. Jun. 2017 (CEST)
6.  Pro Zabia (Diskussion) 17:39, 20. Jun. 2017 (CEST) Ich nutze derzeit (gratis und effizient) www.transkribus.eu (Transkribus, eigentlich für Handschriften konzipiert)
7.  Pro Carsten (Diskussion) 17:51, 20. Jun. 2017 (CEST)
8.  Pro Lydia (Diskussion) 18:33, 20. Jun. 2017 (CEST)
9.  Pro Paulis 19:53, 20. Jun. 2017 (CEST)
10.  Pro Dorades (Diskussion) 21:56, 20. Jun. 2017 (CEST)
11.  Pro --Furfur ^{⁂ Diskussion} 23:19, 21. Jun. 2017 (CEST)
12.  Pro 9xl (Diskussion) 10:32, 22. Jun. 2017 (CEST)
13.  Pro --Guglhupfner (Diskussion) 12:07, 22. Jun. 2017 (CEST)
14.  Pro --HHill (Diskussion) 13:24, 22. Jun. 2017 (CEST)
15.  Pro --Jossi (Diskussion) 13:59, 22. Jun. 2017 (CEST)
16.  Pro --Dominic Z. (Diskussion) 18:23, 22. Jun. 2017 (CEST)
17.  Pro -- S8w4 (Diskussion) 00:33, 23. Jun. 2017 (CEST)
18.  Pro --Sinuhe20 (Diskussion) 17:52, 23. Jun. 2017 (CEST)
19.  Pro --Karl432 (Diskussion) 20:46, 23. Jun. 2017 (CEST)
20.  Pro BB3 (Diskussion) 08:12, 25. Jun. 2017 (CEST)
21.  Pro -- ^Thomas 11:16, 28. Jun. 2017 (CEST)
22.  Pro --Thomas Obermair 4 (Diskussion) 17:15, 28. Jun. 2017 (CEST)
23.  Pro --Έλβις λεβτ (Diskussion) 09:27, 29. Jun. 2017 (CEST)
24.  Pro --Gr1 (Diskussion) 12:41, 29. Jun. 2017 (CEST)
25.  Pro --Batchheizer (Diskussion) 12:41, 30. Jun. 2017 (CEST)
26.  Pro --Sebastian Wallroth 09:16, 1. Jul. 2017 (CEST)
27.  Pro —DerHexer (Disk., Bew.) 23:01, 1. Jul. 2017 (CEST)
28.  Pro -- Mr N (Diskussion) 23:21, 2. Jul. 2017 (CEST)
29.  Pro -- X:: black ::X (Diskussion) 23:52, 2. Jul. 2017 (CEST)
    
    

Commons-Kategorien sollen frei skalierbar in Frage der angezeigten Bilder sein

Was ist das Problem?

Commons-Kategorien sind ein wichtiges Arbeitsmittel, aber leider durch Voreinstellung auf immer maximal 200 Bilder beschränkt. Das behindert oftmals eine effektive Arbeit. Deshalb sollten Commons-Kategorien nicht mehr auf 200 Bilder beschränkt sein.

Wen betrifft das Problem besonders?

Personen, die Bilder sortieren, kategorisieren und anderweitig Ordnung auf Commons schaffen, aber auch Personen die Bilder suchen.

Lösungsvorschlag

• freie Skalierbarkeit mit einer Eingabemaske, in der man seine Wunschzahl einträgt, gerne die aktuellen 200 als Default
• oder vorgegebene Mengen, die am oberen Ende der Kat angeboten werden (etwa 25, 50, 100, 200, 500, 1000 Bilder) und per Button ausgewählt werden können
• eventuell an eine Anmeldung gebunden; dann könnte man auch in den persönlichen Einstellungen eine dauerhafte Wunschzahl angeben

PS: Neben der Anzahl der Bilder eventuell auch Größe skalierbar gestalten. Unabdingbar wichtig ist eine verbesserte Navigation, nicht nur vorhergehende Seite/ nächste Seite. Unsere Kategorien werden derzeit von Panoramiouploads überschwemmt. Niemand klickt sich z. B. 15x (!) durch 3129 Dateien in c:Category:Blasewitz. Sinnvolle Navigation: << . < . 1 . 2 . 3 . ... . Gehe zu Seite ZZ . > . >>, analog Navigation z. B. DNB unten --Frze> ^{> Disk} 09:07, 28. Jun. 2017 (CEST)

Vorschlagende Person

Marcus Cyron Reden 14:09, 11. Jun. 2017 (CEST)

Diskussion

Unterstützung

1.  Pro Marcus Cyron (Einreichende Person)
2.  Pro --MB-one (Diskussion) 18:05, 19. Jun. 2017 (CEST)
3.  Pro -- Karl432 (Diskussion) 21:31, 19. Jun. 2017 (CEST)
4.  Pro -- ^Thomas 13:50, 20. Jun. 2017 (CEST)
5.  Pro Neben der Anzahl der Bilder eventuell auch Größe skalierbar gestalten. Unabdingbar wichtig ist eine verbesserte Navigation, nicht nur vorhergehende Seite/ nächste Seite. Unsere Kategorien werden derzeit von Panoramiouploads überschwemmt. Niemand klickt sich z. B. 15x (!) durch 3129 Dateien in c:Category:Blasewitz. Sinnvolle Navigation: << . < . 1 . 2 . 3 . ... . Gehe zu Seite ZZ . > . >> oder analog Navigation z. B. DNB unten --Frze> ^{> Disk} 14:20, 20. Jun. 2017 (CEST)
6.  Pro -- Michi 19:39, 21. Jun. 2017 (CEST)
7.  Pro --Atamari (Diskussion) 22:56, 23. Jun. 2017 (CEST)
8.  Pro -- Freddy2001 ^DISK 12:18, 24. Jun. 2017 (CEST)
9.  Pro --Thomas Obermair 4 (Diskussion) 17:15, 28. Jun. 2017 (CEST)
10.  Pro KPFC 💬 23:11, 29. Jun. 2017 (CEST)
11.  Pro --Sebastian Wallroth 09:17, 1. Jul. 2017 (CEST)
12.  Pro Brackenheim 20:44, 1. Jul. 2017 (CEST)
13.  Pro —DerHexer (Disk., Bew.) 23:01, 1. Jul. 2017 (CEST)
14.  Pro + Erweiterung der vorsintflutlichen Navigationsoptionen. --Sitacuisses (Diskussion) 15:02, 2. Jul. 2017 (CEST)
15.  Pro -- X:: black ::X (Diskussion) 23:37, 2. Jul. 2017 (CEST)
    
    

Commons: Quelldateien zu Bildern und Karten

Was ist das Problem?

Bisher ist es nicht möglich, Ausgangsdateien (RAWs, AIs, etc.) hochzuladen und den fertigen Endresultat zuzuordnen. Das für dazu, dass sich viele Fotos und Grafiken wenn überhaupt nur mit erheblichenQualitätseinbußen weiterverarbeiten lassen, weil sie nur in einer bearbeiteten Version mit reduzierter Informationstiefe verfügbar sind.

Gerade bei Bearbeitungen in der Foto- und Graphikwerkstatt ist das äußerst hinderlich, weil die Ursprungsdaten über irgendwelche Free-Hoster ausgetauscht werden müssen. Es werden auch viele Bilder auf Commons geladen, die sich überhaupt nicht zur Einbindung in Artikeln o.ä. eignen, weil es z.B. nur die Ausgangsbilder für das Stitching von Panoramabildern eigenen.

Wen betrifft das Problem besonders?

Alle Bildautoren, besonders die die Photos oder SVGs nachbearbeiten.

Lösungsvorschlag

Es sollte möglich sein auch Ausgangsbilder von beliebigen (auch proprietäre) Formaten (wie RAW, AI, CDR, etc) auf Commons zu laden und in einem geschützten Bereich den eigentlichen Endbilder(n) zuzuordnen.

Diese Bilder sollten idealerweise nur für angemeldete Nutzer sichtbar und verlinkbar sein und nicht in Artikel eingebunden werden können.

Vorschlagende Person

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

Diskussion

@Martin Kraft: Warum sollen die Ausgangsbilder nur für angemeldete Benutzer sichtbar sein? Auch unangemeldete Benutzer können Vorschläge an die Grafikwerkstatt geben wenn sie Ausgangangsbilder sehen. --2003:DE:3C1:BA29:8C29:98F6:256E:40 04:31, 20. Jun. 2017 (CEST)

• Der Sinn davon, diese Dateien nur für angemedete Nutzer zugänglich zu machen ist, dass es sich bei diesen Bildern ausdrücklich um Quelldateien und nicht um (Nach-)Nutzungsfertiges Bildmaterial handelt. Es ist also nicht gewünscht, dass diese Dateien, so wie sie sind irgendwo anders eingebunden werden.
• Hinzukommt, dass diese Dateien vorwiegend ein proprietären und nicht in freien Formaten vorliegen werden. D.h. sie fallen strenggenommen nicht in den Projekt-Scope von Commons. Wenn angemeldete Bildautoren sie als Grundlage zur Erstellung von freiem Bildmaterial verwenden ist das mMn vertretbar. Aber nach außen sollten sie nicht sichtbar sein.
• Außerdem wird auf Commons (anders als hier lokal) für die Mitarbeit eh ein Account vorausgesetzt. Und wer sich beteiligen möchte kann sich ja auch einen pseudonymen anlegen.

Ich hoffe, das erklärt es etwas?! // Martin K. (Diskussion) 18:39, 20. Jun. 2017 (CEST)

Unterstützung

1.  Pro Martin Kraft (Einreichende Person)
2.  Pro --MB-one (Diskussion) 18:07, 19. Jun. 2017 (CEST)
3.  Pro -- Karl432 (Diskussion) 21:30, 19. Jun. 2017 (CEST)
4.  Pro DCB (Diskussion • Bewertung) 15:38, 20. Jun. 2017 (CEST)
5.  Pro --Thomas Obermair 4 (Diskussion) 17:15, 28. Jun. 2017 (CEST)
6.  Pro Gr1 (Diskussion) 12:42, 29. Jun. 2017 (CEST) (allerdings im Gegensatz zum Antragsteller verbunden mit dem Wunsch, das auch nicht angemeldeten zur Verfügung stellen zu können)
7.  Pro --Jaquento (Diskussion) 02:37, 30. Jun. 2017 (CEST)
8.  Pro --Sebastian Wallroth 09:17, 1. Jul. 2017 (CEST)
9.  Pro Auch .psd und .xcf Dateien. Die können dann bearbeitet und modifizierte Versionen hochgeladen werden. Siehe dazu: phab:T91914. Eventuell benötigt es ein neues Schwesterprojekt oder Commons-Subprojekt. --Fixuture (Diskussion) 22:47, 1. Jul. 2017 (CEST)
10.  Pro —DerHexer (Disk., Bew.) 23:02, 1. Jul. 2017 (CEST)
11.  Pro --Sitacuisses (Diskussion) 15:04, 2. Jul. 2017 (CEST)
    
    

Commons: Upload Wizard besser für Neulinge und Wettbewerbe nutzbar machen

Was ist das Problem?

Beim Upload Wizard handelt es sich um einen Assistenten zum Hochladen von Dateien, eine Basisfunktion von Commons. Er hat einen großen Einfluss auf Arbeitsprozesse der freiwilligen Mitarbeiter. Bei den großen Wettbewerben Wiki Loves Earth und Wiki Loves Monuments kommt dies besonders zum Tragen. Sehr viele Dateiuploads von Neulingen über den Wizard weisen fehlerhafte Dateibeschreibungsseiten auf, deren Korrektur einen hohen Arbeitsaufwand für erfahrene Benutzer verursacht. Wichtigstes Themenfeld dabei ist die Kategorisierung, daneben beispielsweise auch außerhalb des Beschreibungsfeldes stehende Beschreibungen. Die deutschen Hilfstexte im Upload Wizard sind zu knapp und zu wenig aussagekräftig. Die weiterführenden Links darin führen zu englischsprachigen Versionen der Regelseiten statt zu den vorhandenen deutschsprachigen (c:Commons:Categories statt c:Commons:Kategorien). Diese Seiten sind aber auch viel zu lang, um einem Anfänger rasch einen Einzelschritt des Uploadprozesses zu erklären. Bisherige erste Versuche zur Selbsthilfe erwiesen sich als zu schwierig.

Wen betrifft das Problem besonders?

Betroffen sind insbesondere die großen Wettbewerbe Wiki Loves Earth und Wiki Love Monuments, an denen viele Neubenutzer teilnehmen, die hier auf Anhieb mit Unzulänglichkeiten konfrontiert werden. Ebenso betroffen sind die erfahrenen Benutzer, die dabei viel Zeit für die Korrektur vermeidbarer Fehler verwenden müssen.

Lösungsvorschlag

• Die deutschen Pop-up-Hilfstexte des Uploadformulars aussagekräftiger und mit Beispielen gestalten. Für die Kategorisierung muss dort etwa vermittelt werden:
  • möglichst spezifische Kategorie suchen (Beispiel)
  • Bild nur in der spezifischsten Kategorieebene platzieren und nicht auch in darüberliegenden (Beispiel)
  • keine allgemeinen Tags hinzufügen (Beispiel)
  • Kategoriebezeichnungen sind abgesehen von Namen englischsprachig
• Die weiterführenden Links direkt auf die deutschsprachigen Regelseiten leiten.
• Projektspezifische Versionen des Formulars anbieten für die großen Wettbewerbe wie WLE und WLM. Hilfshinweise und Beispiele können ans jeweilige Themenfeld angepasst werden, unbenötigte Felder gesperrt.
• Das Formular direkt mit einem Tool wie GeoLocator verbinden, das jedoch alleine auf die in Commons benötigten Vorlagenformate eingeschränkt sein sollte und keine hier überflüssigen Auswahlmöglichkeiten hat.
• Eine Basisfunktion von derartiger Bedeutung sollte zentral von den bezahlten Mitarbeitern gewartet bzw. angeboten werden.
  Vorschlagende Person

Sitacuisses (Diskussion) 18:13, 11. Jun. 2017 (CEST)

Diskussion

Hallo Sitacuisses, vielen Dank für deinen Wunsch! Nur ein kleiner Hinweis: In dem Wunsch sind sowohl Dinge enthalten, die das Technische Wünsche Team lösen kann, als auch Dinge, die die Community selbst machen müsste. Beispiel: Der Sprachlink zu den weiterführenden Informationen kann korrigiert werden & die Hilfetexte im Upload-Wizard selbst könnten in Zusammenarbeit mit den Machern vom Upload Wizard und der Community vermutlich verbessert werden, aber der Text zu den Kategorien auf Commons ist in der Verantwortung der Commons-Community selbst - d.h., da könntest du das, was dir zu umständlich vorkommt, ggf. selbst anpassen. Da die Abstimmung morgen beginnt, würde ich den Wunsch nun genauso lassen, aber wollte schon mal darauf hinweisen, dass das Technik-Team nur bei einem Teil des Wunsches unterstützen kann. Lieben Gruß, --Birgit Müller (WMDE) (Diskussion) 19:50, 18. Jun. 2017 (CEST)

@Birgit Müller (WMDE):: Da sprichst du ja einen weiteren Teil des Problems an. Ich habe auf den Link zur englischen Version vor längerer Zeit schon einmal irgendwo auf Commons aufmerksam gemacht. Das Ergebnis war, dass er nicht so einfach an eine andere Sprachversion angepasst werden konnte, sondern "hardcoded" war. Mein Anliegen geht im Kern darum auch viel weiter: Der Upload Wizard gehört zur Basisfunktionalität auf Commons, und seine Funktion oder fehlende Funktion hat einen enormen Einfluss auf die Arbeitsprozesse der dortigen Freiwilligen. Wie kann es sein, dass solche Basisfunktionen nicht zentral gewartet werden? Als einfacher Benutzer kann ich zwischen all den notwendigen Korrekturen nicht auch noch nachforschen, welche Stelle bzw. Person eventuell verantwortlich ist, ob derjenige Freiwillige momentan gerade Zeit hat oder vielleicht gar nicht mehr an Wiki-Projekten arbeitet. Man kann von Freiwilligen auch nicht so einfach verlangen, dass sie weitere Versionen des Wizards herstellen. Ich ergänze meine Vorschlag daher noch in diese Richtung. --Sitacuisses (Diskussion) 23:21, 18. Jun. 2017 (CEST)

Unterstützung

1.  Pro Sitacuisses (Einreichende Person)
2.  Pro --FNDE 12:05, 20. Jun. 2017 (CEST)
3.  Pro (nicht signierter Beitrag von Ziko (Diskussion | Beiträge) )
4.  Pro --Thomas Obermair 4 (Diskussion) 17:16, 28. Jun. 2017 (CEST)
5.  Pro --Fixuture (Diskussion) 22:43, 1. Jul. 2017 (CEST)
   
   

Commons: iOS-App zum Hochladen von Bildern

Was ist das Problem?

Für iPhones gibt es kein App, mit dem man schnell und einfach Bilder nach Commons hochladen kann. Dabei hat heute ja jeder immer sein Smartphone dabei und könnte laufend Bilder für Wikipedia-Artikel beitragen.

Es gab mal Apps, aber die funktionieren alle nicht mehr …

Wen betrifft das Problem besonders?

alle User mit iPhone oder iPad

Lösungsvorschlag

ein neues App, das auch gewartet wird und nicht schon nach ein paar Monaten wieder offline geht.

Vorschlagende Person

Lars (User.Albinfo) 22:34, 11. Jun. 2017 (CEST)

Diskussion

Dazu hier mal der Link zur App, die ich mal für einige Zeit weiter entwickelt habe (weil die Foundation die Entwicklung eingestellt hatte), ich aber Zeitlich nicht zur Weiterleitung komme: https://github.com/lyrk/Commons — kann als Grundlage genommen werden, vielleicht will man aber auch einfach neu anfangen um sich nicht mit dem ganzen alten Kram rumzuschlagen, sondern neu in Swift anfangen kann zu programmieren. Ist halt dann auch mit Pflege usw verbunden. Ubahnverleih (Diskussion) 07:35, 15. Jun. 2017 (CEST)

Das fördert nur unzureichendes, schlecht kategorisiertes und schlecht beschriebenes Bildmaterial. (Siehe auch Datenübernahme des Panoramiobestands.) (Und das heißt nicht, dass dann nur schlechtes Material kommt, aber die Hemmschwelle sinkt. Es fehlt dann auch oft an der üblichen Nachbearbeitung.) --XRay ^Disk. 14:03, 21. Jun. 2017 (CEST)

Es gibt seit vielen Jahren ein App für Android, das genau diese Funktion erfüllt, und nicht wegen Datenmüll kritisiert wird: c:Commons:Mobile app

Ist von Usern von iPhones und iPads mehr Müll zu erwarten als von Android-Usern? Oder liegt hier ein Apple-ist-böse-Reflex vor?

Ich fühle mich jedenfalls benachteiligt und eingeschränkt … --Lars (User.Albinfo) 15:37, 24. Jun. 2017 (CEST)

Bei der Antwort würde ich vielleicht mal bedenken, dass hier nur auf den Vorschlag reagiert wurde. Ein Aussage zu anderen Betriebssystemen wurde nicht gemacht, nicht einmal in dem Vorschlag. Eine Überreaktion halte ich daher doch eher für unangemessen. Also immer mit der Ruhe. ;-) --XRay ^Disk. 20:58, 25. Jun. 2017 (CEST)

Ich wäre ja ruhig geblieben, wenn die ablehnenden Voten logisch nachvollziehbar wären. Aber so was wirft einen halt aus der Bahn und man sucht nach anderen Ursachen. --Lars (User.Albinfo) 12:25, 26. Jun. 2017 (CEST)

Nein, es sollte kein Markenbashing sein. Diese Spielchen treibe ich schon seit Jahrzehnten nicht mehr. Vielleicht reagierst du zu empfindlich, wenn ich das (hoffentlich) so sagen darf. Ich habe auch von anderen Erfahrungen mit den anderen Upload-Apps gelesen und die waren mitnichten positiv. Wikimedia Commons wird in Schüben mehr von Quantität als Qualität geflutet. Ich als Amateurfotograf hoffe, dass auch bei Wikipedia wie bei den textlichen Inhalten mehr Wert auf besseres Bildmaterial gelegt wird. Panoramio mag ein Beispiel sein, die Kategorie mit den mobilen Uploads (über 50.000 Bilder) ein anderes. Mein Fokus liegt folglich eher auf der Bildqualität. Als Amateurfotograf sehe ich jeden Tag Smartphonephotos, schnell geknipst. (Das Zitat eines unbekannten Autors kennst du? Diese: Zum Fotografieren braucht man Zeit. Wer keine Zeit hat, kann ja knipsen.) Man hat leider den Eindruck, dass dies die Masse ist. Bei den Kandidaten für Qualitätsbilder fallen Smartphonephotos oft als unzureichend auf. Dasselbe trifft auch auf einfache Kompaktkameras zu. Selbst wenn die Gestaltung wirklich toll ist, fehlt es der Technik an einer vernünftigen Optik und einem akzeptablen Sensor. Diese lange Antwort wollte ich eigentlich gar nicht schreiben, hoffe aber, dich damit beruhigt zu haben. --XRay ^Disk. 20:55, 26. Jun. 2017 (CEST)

Der Vergleich mit Panoramio (hat mir auch viel Arbeit beim Kategorisieren bereitet) hinkt meines Erachtens – und der Vergleich mit den Erfahrungen vom Hörensagen mit anderen Upload-Apps kommt reichlich spät.

Klar ist jedes Qualitätsfoto eine Freude und eine Bereicherung des Projekts. Aber viele Artikel sind unbebildert oder schlecht bebildert. Da wäre es schön, wenn es einen einfachen Weg gäbe, über das iPhone einen ordentlichen Schnappschuss hochzuladen (ohne immer den Umweg über den Computer nehmen zu müssen). Und die Qualität der meisten Smartphone-Kameras ist heute besser wie vieles, was vor zehn Jahren mit normalen Digitalkameras aufgenommen worden ist.

So schlimm ist es nicht mit dem Datenmüll, wenn man sicherstellt, dass keine unkategorisierten und unbeschriebenen Bilder hochgeladen werden (wenn es mit Arbeit verbunden wird, werden auch nicht Abertausende von Bilder hochgeladen). --Lars (User.Albinfo) 23:03, 26. Jun. 2017 (CEST)

Ich greife das Thema "Hörensagen" noch einmal auf. Das sehe ich nicht. Auch nicht, dass es spät kommt. (Für eine Abstimmung muss man keine ausführlichen Vergleiche anstellen.) Schau mal unter commons:Category:Mobile upload. Dazu darf ich ergänzen, dass Kategoriezwang nicht bedeutet, dass auch sinnvoll Kategorien vergeben werden. Zu oft musste ich schon wild vergebene Kategorien wieder entfernen. Aber die Qualität der Kategorisierung ist ein anderes Thema. Mängel gibt es bei der Bildverwaltung schon etliche. BTW: Um unbebilderte Artikel mit Bildern zu versehen, gibt es viele Wege. Bei Wikimedia Commons könnte man Upload und Verwaltung vereinfachen und auch mehr Fotografinnen und Fotografen animieren. Zu oft musste ich schon sehen, dass sich gute Fotografinnen und Fotografen wieder abwenden. Das ähnelt dem Abwenden von Autorinnen und Autoren hier, wobei ich persönlich bei Wikipedia dem Verhalten einiger Mitautoren dafür eine gewisse Schuld gebe. --XRay ^Disk. 06:35, 27. Jun. 2017 (CEST)

Ach ja, du kennst bestimmt diese Kategorien: c:Category:Media needing categories, c:Category:Unidentified subjects, c:Category:Images for cleanup. Sorry, gehört nicht zum Thema. --XRay ^Disk. 06:58, 27. Jun. 2017 (CEST)

Unterstützung

1.  Pro Albinfo (Einreichende Person)
2.  Kontra Das fördert nur unzureichendes, schlecht kategorisiertes und schlecht beschriebenes Bildmaterial. (Siehe auch Datenübernahme des Panoramiobestands.) (Und das heißt nicht, dass dann nur schlechtes Material kommt, aber die Hemmschwelle sinkt. Es fehlt dann auch oft an der üblichen Nachbearbeitung.) --XRay ^Disk. 14:03, 21. Jun. 2017 (CEST) [Antworten/Diskussion siehe oben]
3.  Kontra Dito. --Jü (Diskussion) 06:54, 22. Jun. 2017 (CEST)
4.  Kontra Per 2 u. 3 -- Freddy2001 ^DISK 12:19, 24. Jun. 2017 (CEST)
5.  Pro Ich bin seit Jahren zufriedener Nutzer der Android-App und fände ein Unterstützung von iOS ebenfalls wünschenswert. Mich würde es auch nicht stören, wenn zukünftig vor dem Upload mindestens x Zeichen Beschreibung und mindestens eine Kategorie gefordert würden. Eine komplette Blockade von mobilen Upload-Möglichkeiten halte ich aber für den falschen Weg, um die Qualitätsprobleme in den Griff zu bekommen. --Tkarcher (Diskussion) 09:29, 26. Jun. 2017 (CEST)
6.  Pro --Thomas Obermair 4 (Diskussion) 17:16, 28. Jun. 2017 (CEST)
7.  Pro --Morten Haan 🎲 Wikipedia ist für Leser da • Skin-Entwurf 00:11, 29. Jun. 2017 (CEST)
8.  Pro --Braveheart ^{Welcome to Project Mayhem} 18:51, 29. Jun. 2017 (CEST) Ist auf Android jetzt schon möglich, das sollt dann auch auf iOS kein Problem sein.
9.  Pro —SDKmac (Disk., Bew.) 02:23, 30. Jun. 2017 (CEST)
10.  Pro --Sebastian Wallroth 09:18, 1. Jul. 2017 (CEST)
11.  Pro (mit Einschränkung:) Übername nur Bilder die in den Exifdaten auch die Koordinaten haben oder deren Verortung bereits beim Hochladen in anderer Form mit kommt (auf commons z.b.: {{object location}} {{Location dec}} odere ähnlich passendes, denn sonst wird das nachträgliche kategoriesieren bis zur Unmöglichkeit schwer gemacht) --Finte (Diskussion) 01:40, 23. Jan. 2018 (CET)