Wikipedia:Umfragen/Technische Wünsche 2017/Schwesterprojekte

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

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.

[Quelltext bearbeiten]
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)[Beantworten]

Unterstützung
  1. Pro KPFC (Einreichende Person)
  2. Pro --MB-one (Diskussion) 17:38, 19. Jun. 2017 (CEST)[Beantworten]
  3. Pro DCB (DiskussionBewertung) 15:31, 20. Jun. 2017 (CEST)[Beantworten]
  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)[Beantworten]
  5. Pro --Marsupium (Diskussion) 18:07, 23. Jun. 2017 (CEST)[Beantworten]
  6. Pro -- Freddy2001 DISK 12:13, 24. Jun. 2017 (CEST)[Beantworten]
  7. Pro --Thomas Obermair 4 (Diskussion) 17:04, 28. Jun. 2017 (CEST)[Beantworten]
  8. Pro --Fixuture (Diskussion) 21:14, 1. Jul. 2017 (CEST)[Beantworten]

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

[Quelltext bearbeiten]
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)[Beantworten]

Unterstützung
  1. Pro JostGudelius (Einreichende Person)
  2. Pro Kontrollstelle Kundl 18:44, 20. Jun. 2017 (CEST)[Beantworten]
  3. Pro Conny 13:52, 21. Jun. 2017 (CEST).[Beantworten]
  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)[Beantworten]
  5. Kontra Wie Furfur und in der Disk. angemerkt. Das Vorhaben ist einfach nicht realistisch. // Martin K. (Diskussion) 23:22, 21. Jun. 2017 (CEST)[Beantworten]
  6. Pro -- (Diskussion) 06:47, 22. Jun. 2017 (CEST)[Beantworten]
  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)[Beantworten]
  8. Pro --GodeNehler (Diskussion) 23:09, 22. Jun. 2017 (CEST)[Beantworten]
  9. Kontra an der Realität vorbei (s. Diskussions-Kommentar) -- User: Perhelion 15:50, 23. Jun. 2017 (CEST)[Beantworten]
  10. Kontra, nicht realistisch. Neuerstellung ist qualitativ besser als irgendwas halbautomatisches. Inkscape reicht dafür aus. -- Freddy2001 DISK 12:14, 24. Jun. 2017 (CEST)[Beantworten]
  11. Pro --Thomas Obermair 4 (Diskussion) 17:05, 28. Jun. 2017 (CEST)[Beantworten]
  12. Kontra --Gr1 (Diskussion) 12:36, 29. Jun. 2017 (CEST) Siehe Contra-Vorredner[Beantworten]
  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 ...[Beantworten]
  14. Kontra SVG taugt nix für Nachnutzer. --M@rcela 05:36, 3. Jul. 2017 (CEST)[Beantworten]
(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)[Beantworten]

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

[Quelltext bearbeiten]
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)[Beantworten]

Unterstützung
  1. Pro Raymond (Einreichende Person)
  2. Pro -- Marcus Cyron Reden 10:32, 19. Jun. 2017 (CEST)[Beantworten]
  3. Pro --Leyo 10:34, 19. Jun. 2017 (CEST)[Beantworten]
  4. Pro --Geolina mente et malleo 17:47, 19. Jun. 2017 (CEST)[Beantworten]
  5. Pro Gestumblindi 23:51, 19. Jun. 2017 (CEST)[Beantworten]
  6. Pro  hugarheimur 08:11, 20. Jun. 2017 (CEST)[Beantworten]
  7. Pro DCB (DiskussionBewertung) 15:32, 20. Jun. 2017 (CEST)[Beantworten]
  8. Pro --Smial (Diskussion) 17:30, 20. Jun. 2017 (CEST)[Beantworten]
  9. Pro --M@rcela 17:35, 20. Jun. 2017 (CEST)[Beantworten]
  10. Pro // Martin K. (Diskussion) 18:03, 20. Jun. 2017 (CEST)[Beantworten]
  11. Pro --jcornelius Benutzer Diskussion:Jcornelius 11:45, 21. Jun. 2017 (CEST) absolut![Beantworten]
  12. Pro Conny 13:52, 21. Jun. 2017 (CEST).[Beantworten]
  13. Pro -- Michi 19:38, 21. Jun. 2017 (CEST)[Beantworten]
  14. Pro --NearEMPTiness (Diskussion) 21:38, 21. Jun. 2017 (CEST)[Beantworten]
  15. Pro -- (Diskussion) 06:48, 22. Jun. 2017 (CEST)[Beantworten]
  16. Pro --Suriyaa Kudo · Archiv (Diskussion) 13:36, 22. Jun. 2017 (CEST)[Beantworten]
  17. Pro --Magnus (Diskussion) 16:06, 22. Jun. 2017 (CEST)[Beantworten]
  18. Pro --TypeZero (Diskussion) 17:52, 22. Jun. 2017 (CEST)[Beantworten]
  19. Pro -- User: Perhelion 15:57, 23. Jun. 2017 (CEST)[Beantworten]
  20. Pro --Nichtich (Diskussion) 22:27, 23. Jun. 2017 (CEST)[Beantworten]
  21. Pro -- Freddy2001 DISK 12:15, 24. Jun. 2017 (CEST)[Beantworten]
  22. Pro --Divof (Diskussion) 19:41, 24. Jun. 2017 (CEST)[Beantworten]
  23. Pro --DianeAnna (Diskussion) 20:45, 25. Jun. 2017 (CEST)[Beantworten]
  24. Pro NNW 16:34, 27. Jun. 2017 (CEST)[Beantworten]
  25. Pro --Incabell (Diskussion) 17:54, 27. Jun. 2017 (CEST)[Beantworten]
  26. Pro --Thomas Obermair 4 (Diskussion) 17:05, 28. Jun. 2017 (CEST)[Beantworten]
  27. Pro --Ak ccm (Diskussion) 23:58, 28. Jun. 2017 (CEST)[Beantworten]
  28. Pro KPFC💬 23:04, 29. Jun. 2017 (CEST)[Beantworten]
  29. Pro --1971markus ⇒ Laberkasten ... 23:32, 29. Jun. 2017 (CEST)[Beantworten]
  30. ProSDKmac (Disk., Bew.) 02:23, 30. Jun. 2017 (CEST)[Beantworten]
  31. Pro --Sebastian Wallroth 09:06, 1. Jul. 2017 (CEST)[Beantworten]
  32. Pro -- Mboesch (Diskussion) 11:44, 1. Jul. 2017 (CEST)[Beantworten]
  33. Pro --Entbert (Diskussion) 16:17, 2. Jul. 2017 (CEST)[Beantworten]
  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)[Beantworten]

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

[Quelltext bearbeiten]
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)[Beantworten]

Unterstützung
  1. Pro Mboesch (Einreichende Person)
  2. Pro --MB-one (Diskussion) 17:41, 19. Jun. 2017 (CEST)[Beantworten]
  3. Pro -- Karl432 (Diskussion) 21:34, 19. Jun. 2017 (CEST)[Beantworten]
  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). [Beantworten]
  5. Pro --M@rcela 17:36, 20. Jun. 2017 (CEST) Ich möchte den Reworkhelper wiederhaben![Beantworten]
  6. Pro --jcornelius Benutzer Diskussion:Jcornelius 11:45, 21. Jun. 2017 (CEST)[Beantworten]
  7. Pro Siehe phab:T110409 und phab:T69283. --El Grafo (COM) 16:09, 22. Jun. 2017 (CEST)[Beantworten]
  8. Pro Allerdings wie Speravir schon sagt, redundant zu derivativeFX. -- User: Perhelion 19:09, 23. Jun. 2017 (CEST)[Beantworten]
  9. Pro -- Freddy2001 DISK 12:15, 24. Jun. 2017 (CEST)[Beantworten]
  10. Pro --Thomas Obermair 4 (Diskussion) 17:06, 28. Jun. 2017 (CEST)[Beantworten]
  11. Pro --Sebastian Wallroth 09:06, 1. Jul. 2017 (CEST)[Beantworten]
  12. Pro --Sitacuisses (Diskussion) 14:40, 2. Jul. 2017 (CEST)[Beantworten]

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

[Quelltext bearbeiten]
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)[Beantworten]

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

Vereinfachtes Auffinden von Commons-Kategorien

[Quelltext bearbeiten]
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)[Beantworten]

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

Wiederherstellung der Funktion des Pointers in Bing Maps

[Quelltext bearbeiten]
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)[Beantworten]

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

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

[Quelltext bearbeiten]
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

Z thomas Thomas 11:35, 31. Mai 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro Z thomas (Einreichende Person)
  2. Pro DCB (DiskussionBewertung) 15:34, 20. Jun. 2017 (CEST)[Beantworten]
  3. Pro Conny 13:54, 21. Jun. 2017 (CEST).[Beantworten]
  4. Kontra Halte ich nicht für realistisch. --Magnus (Diskussion) 16:07, 22. Jun. 2017 (CEST)[Beantworten]
  5. Pro --GodeNehler (Diskussion) 23:11, 22. Jun. 2017 (CEST)[Beantworten]
  6. Pro --Nichtich (Diskussion) 22:27, 23. Jun. 2017 (CEST)[Beantworten]
  7. Pro -- Freddy2001 DISK 12:16, 24. Jun. 2017 (CEST)[Beantworten]
  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)[Beantworten]
  9. Pro --Thomas Obermair 4 (Diskussion) 17:08, 28. Jun. 2017 (CEST)[Beantworten]
  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.[Beantworten]
  11. Pro --Sebastian Wallroth 09:10, 1. Jul. 2017 (CEST)[Beantworten]
  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)[Beantworten]

Benachrichtigung zu Löschdiskussionen bei Interwiki-Artikeln

[Quelltext bearbeiten]
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)[Beantworten]

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

[Quelltext bearbeiten]
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

Z thomas Thomas 13:27, 31. Mai 2017 (CEST)[Beantworten]

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

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

[Quelltext bearbeiten]
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)[Beantworten]

Unterstützung
  1. Pro Rudolph Buch (Einreichende Person)
  2. Pro DCB (DiskussionBewertung) 15:34, 20. Jun. 2017 (CEST)[Beantworten]
  3. Pro --Thomas Obermair 4 (Diskussion) 17:09, 28. Jun. 2017 (CEST)[Beantworten]
  4. Pro -- X:: black ::X (Diskussion) 22:58, 2. Jul. 2017 (CEST)[Beantworten]

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

[Quelltext bearbeiten]
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

Z thomas Thomas 15:53, 31. Mai 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro Z thomas (Einreichende Person)
  2. Pro --ManfredK (Diskussion) 16:30, 20. Jun. 2017 (CEST)[Beantworten]
  3. Pro -jkb- 13:59, 21. Jun. 2017 (CEST)[Beantworten]
  4. Pro -- Michi 19:39, 21. Jun. 2017 (CEST)[Beantworten]
  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)[Beantworten]
  6. Pro --Thomas Obermair 4 (Diskussion) 17:09, 28. Jun. 2017 (CEST)[Beantworten]
  7. Pro Und dazu am besten noch Benachrichtigungen bei neuen Benutzungen. --Fixuture (Diskussion) 21:33, 1. Jul. 2017 (CEST)[Beantworten]

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

[Quelltext bearbeiten]
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)[Beantworten]

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

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

[Quelltext bearbeiten]
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)[Beantworten]

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

Commons: Sortierung der Bilder in den Kategorien

[Quelltext bearbeiten]
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)[Beantworten]

Vorschlagende Person

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

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[Beantworten]
  3. Pro für die optionale Variante --MB-one (Diskussion) 17:57, 19. Jun. 2017 (CEST)[Beantworten]
  4. Pro für die optionale variante mit weiteren Parametern wie Größe, Aufnahmedatum, Uploadedatum, Uploder --Z thomas Thomas 13:45, 20. Jun. 2017 (CEST)[Beantworten]
  5. Pro --HerrAdams (D) 18:51, 20. Jun. 2017 (CEST)[Beantworten]
  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)[Beantworten]
  7. Pro Für eine wählbare Sorierung. --Magnus (Diskussion) 16:08, 22. Jun. 2017 (CEST)[Beantworten]
  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)[Beantworten]
  9. Pro --Atamari (Diskussion) 22:53, 23. Jun. 2017 (CEST)[Beantworten]
  10. Pro --Thomas Obermair 4 (Diskussion) 17:12, 28. Jun. 2017 (CEST)[Beantworten]
  11. Pro --Frze> > Disk 11:53, 30. Jun. 2017 (CEST)[Beantworten]
  12. Pro --Sebastian Wallroth 09:14, 1. Jul. 2017 (CEST)[Beantworten]
  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)[Beantworten]
  14. ProDerHexer (Disk.Bew.) 22:55, 1. Jul. 2017 (CEST)[Beantworten]
  15. Pro --Sitacuisses (Diskussion) 14:59, 2. Jul. 2017 (CEST)[Beantworten]
  16. Pro für wählbare Sortierungsoptionen. --Zaccarias (Diskussion) 19:51, 2. Jul. 2017 (CEST)[Beantworten]
  17. Pro --ProloSozz (Diskussion) 23:17, 2. Jul. 2017 (CEST)[Beantworten]
  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)[Beantworten]

Upload Wizard soll sich meinen Namen merken

[Quelltext bearbeiten]
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)[Beantworten]

Unterstützung
  1. Pro MichaelSchoenitzer (Einreichende Person)
  2. Pro --FNDE 12:02, 20. Jun. 2017 (CEST)[Beantworten]
  3. Pro --Z thomas Thomas 13:47, 20. Jun. 2017 (CEST)[Beantworten]
  4. Pro --Thomas Obermair 4 (Diskussion) 17:13, 28. Jun. 2017 (CEST)[Beantworten]
  5. Pro --ProloSozz (Diskussion) 23:18, 2. Jul. 2017 (CEST)[Beantworten]

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

[Quelltext bearbeiten]
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)[Beantworten]

Unterstützung
  1. Pro Sitacuisses (Einreichende Person)
  2. Pro --Z thomas Thomas 13:49, 20. Jun. 2017 (CEST)[Beantworten]
  3. Pro Hermannh (Diskussion) 21:58, 20. Jun. 2017 (CEST)[Beantworten]
  4. Pro --Thomas Obermair 4 (Diskussion) 17:13, 28. Jun. 2017 (CEST)[Beantworten]
  5. Pro --Sebastian Wallroth 09:15, 1. Jul. 2017 (CEST)[Beantworten]
  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)[Beantworten]

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

[Quelltext bearbeiten]
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)[Beantworten]

Unterstützung
  1. Pro Medea7 (Einreichende Person)
  2. Pro --Thomas Obermair 4 (Diskussion) 17:14, 28. Jun. 2017 (CEST)[Beantworten]
  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)[Beantworten]

Darstellung von sphärischen Panoramas in Wikipedia

[Quelltext bearbeiten]
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)[Beantworten]

Unterstützung
  1. Pro Poco a poco (Einreichende Person)
  2. Pro  hugarheimur 08:13, 20. Jun. 2017 (CEST)[Beantworten]
  3. Pro --FNDE 12:04, 20. Jun. 2017 (CEST)[Beantworten]
  4. Pro --Z thomas Thomas 13:46, 20. Jun. 2017 (CEST)[Beantworten]
  5. Pro DCB (DiskussionBewertung) 15:36, 20. Jun. 2017 (CEST)[Beantworten]
  6. Pro Zabia (Diskussion) 17:35, 20. Jun. 2017 (CEST)[Beantworten]
  7. Pro --Andropov (Diskussion) 17:55, 20. Jun. 2017 (CEST)[Beantworten]
  8. Pro // Martin K. (Diskussion) 18:15, 20. Jun. 2017 (CEST) / Gerne auch im Rahmen der generellen Einbindung interaktiver Medieninhalte[Beantworten]
  9. Pro --Claell (Diskussion) 19:27, 20. Jun. 2017 (CEST)[Beantworten]
  10. Pro --Trockennasenaffe (Diskussion) 09:31, 21. Jun. 2017 (CEST)[Beantworten]
  11. Pro -- Michi 19:39, 21. Jun. 2017 (CEST)[Beantworten]
  12. Pro --MGChecker – (📞| 📝| Bewertung) 20:45, 21. Jun. 2017 (CEST)[Beantworten]
  13. Pro --Jossi (Diskussion) 13:53, 22. Jun. 2017 (CEST)[Beantworten]
  14. Pro --GodeNehler (Diskussion) 23:14, 22. Jun. 2017 (CEST)[Beantworten]
  15. Pro idealerweise auch für 360° Videos --El Grafo (COM) 08:49, 23. Jun. 2017 (CEST)[Beantworten]
  16. Pro --Daniel749 Disk. (STWPST) 22:10, 23. Jun. 2017 (CEST)[Beantworten]
  17. Pro --Nichtich (Diskussion) 22:30, 23. Jun. 2017 (CEST)[Beantworten]
  18. Pro -- Freddy2001 DISK 12:18, 24. Jun. 2017 (CEST)[Beantworten]
  19. Pro --DianeAnna (Diskussion) 22:03, 25. Jun. 2017 (CEST)[Beantworten]
  20. Pro --Noobius2 (Diskussion)
  21. Pro --Thomas Obermair 4 (Diskussion) 17:14, 28. Jun. 2017 (CEST)[Beantworten]
  22. Pro --Kolossos 20:57, 29. Jun. 2017 (CEST)[Beantworten]
  23. Pro --Schönitzer (Diskussion) 20:55, 30. Jun. 2017 (CEST)[Beantworten]
  24. Pro --Sebastian Wallroth 09:15, 1. Jul. 2017 (CEST)[Beantworten]
  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)[Beantworten]
  26. ProDerHexer (Disk.Bew.) 22:58, 1. Jul. 2017 (CEST)[Beantworten]
  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.[Beantworten]


Verbesserung von OCR für Frakturschrift

[Quelltext bearbeiten]
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)[Beantworten]

Unterstützung
  1. Pro A. Wagner (Einreichende Person)
  2. Pro Jeb (Diskussion) 20:28, 19. Jun. 2017 (CEST)[Beantworten]
  3. Pro --Unendlicheweiten (Dialog) 23:24, 19. Jun. 2017 (CEST)[Beantworten]
  4. Pro Conny 14:43, 20. Jun. 2017 (CEST).[Beantworten]
  5. Pro DCB (DiskussionBewertung) 15:37, 20. Jun. 2017 (CEST)[Beantworten]
  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)[Beantworten]
  7. Pro Carsten (Diskussion) 17:51, 20. Jun. 2017 (CEST)[Beantworten]
  8. Pro Lydia (Diskussion) 18:33, 20. Jun. 2017 (CEST)[Beantworten]
  9. Pro Paulis 19:53, 20. Jun. 2017 (CEST)[Beantworten]
  10. Pro Dorades (Diskussion) 21:56, 20. Jun. 2017 (CEST)[Beantworten]
  11. Pro --Furfur Diskussion 23:19, 21. Jun. 2017 (CEST)[Beantworten]
  12. Pro 9xl (Diskussion) 10:32, 22. Jun. 2017 (CEST)[Beantworten]
  13. Pro --Guglhupfner (Diskussion) 12:07, 22. Jun. 2017 (CEST)[Beantworten]
  14. Pro --HHill (Diskussion) 13:24, 22. Jun. 2017 (CEST)[Beantworten]
  15. Pro --Jossi (Diskussion) 13:59, 22. Jun. 2017 (CEST)[Beantworten]
  16. Pro --Dominic Z. (Diskussion) 18:23, 22. Jun. 2017 (CEST)[Beantworten]
  17. Pro -- S8w4 (Diskussion) 00:33, 23. Jun. 2017 (CEST)[Beantworten]
  18. Pro --Sinuhe20 (Diskussion) 17:52, 23. Jun. 2017 (CEST)[Beantworten]
  19. Pro --Karl432 (Diskussion) 20:46, 23. Jun. 2017 (CEST)[Beantworten]
  20. Pro BB3 (Diskussion) 08:12, 25. Jun. 2017 (CEST)[Beantworten]
  21. Pro --Z thomas Thomas 11:16, 28. Jun. 2017 (CEST)[Beantworten]
  22. Pro --Thomas Obermair 4 (Diskussion) 17:15, 28. Jun. 2017 (CEST)[Beantworten]
  23. Pro --Έλβις λεβτ (Diskussion) 09:27, 29. Jun. 2017 (CEST)[Beantworten]
  24. Pro --Gr1 (Diskussion) 12:41, 29. Jun. 2017 (CEST)[Beantworten]
  25. Pro --Batchheizer (Diskussion) 12:41, 30. Jun. 2017 (CEST)[Beantworten]
  26. Pro --Sebastian Wallroth 09:16, 1. Jul. 2017 (CEST)[Beantworten]
  27. ProDerHexer (Disk.Bew.) 23:01, 1. Jul. 2017 (CEST)[Beantworten]
  28. Pro -- Mr N (Diskussion) 23:21, 2. Jul. 2017 (CEST)[Beantworten]
  29. Pro -- X:: black ::X (Diskussion) 23:52, 2. Jul. 2017 (CEST)[Beantworten]

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

[Quelltext bearbeiten]
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)[Beantworten]
Vorschlagende Person

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

Unterstützung
  1. Pro Marcus Cyron (Einreichende Person)
  2. Pro --MB-one (Diskussion) 18:05, 19. Jun. 2017 (CEST)[Beantworten]
  3. Pro -- Karl432 (Diskussion) 21:31, 19. Jun. 2017 (CEST)[Beantworten]
  4. Pro --Z thomas Thomas 13:50, 20. Jun. 2017 (CEST)[Beantworten]
  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)[Beantworten]
  6. Pro -- Michi 19:39, 21. Jun. 2017 (CEST)[Beantworten]
  7. Pro --Atamari (Diskussion) 22:56, 23. Jun. 2017 (CEST)[Beantworten]
  8. Pro -- Freddy2001 DISK 12:18, 24. Jun. 2017 (CEST)[Beantworten]
  9. Pro --Thomas Obermair 4 (Diskussion) 17:15, 28. Jun. 2017 (CEST)[Beantworten]
  10. Pro KPFC💬 23:11, 29. Jun. 2017 (CEST)[Beantworten]
  11. Pro --Sebastian Wallroth 09:17, 1. Jul. 2017 (CEST)[Beantworten]
  12. Pro Brackenheim 20:44, 1. Jul. 2017 (CEST)[Beantworten]
  13. ProDerHexer (Disk.Bew.) 23:01, 1. Jul. 2017 (CEST)[Beantworten]
  14. Pro + Erweiterung der vorsintflutlichen Navigationsoptionen. --Sitacuisses (Diskussion) 15:02, 2. Jul. 2017 (CEST)[Beantworten]
  15. Pro -- X:: black ::X (Diskussion) 23:37, 2. Jul. 2017 (CEST)[Beantworten]

Commons: Quelldateien zu Bildern und Karten

[Quelltext bearbeiten]
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)[Beantworten]

Unterstützung
  1. Pro Martin Kraft (Einreichende Person)
  2. Pro --MB-one (Diskussion) 18:07, 19. Jun. 2017 (CEST)[Beantworten]
  3. Pro -- Karl432 (Diskussion) 21:30, 19. Jun. 2017 (CEST)[Beantworten]
  4. Pro DCB (DiskussionBewertung) 15:38, 20. Jun. 2017 (CEST)[Beantworten]
  5. Pro --Thomas Obermair 4 (Diskussion) 17:15, 28. Jun. 2017 (CEST)[Beantworten]
  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)[Beantworten]
  7. Pro --Jaquento (Diskussion) 02:37, 30. Jun. 2017 (CEST)[Beantworten]
  8. Pro --Sebastian Wallroth 09:17, 1. Jul. 2017 (CEST)[Beantworten]
  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)[Beantworten]
  10. ProDerHexer (Disk.Bew.) 23:02, 1. Jul. 2017 (CEST)[Beantworten]
  11. Pro --Sitacuisses (Diskussion) 15:04, 2. Jul. 2017 (CEST)[Beantworten]

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

[Quelltext bearbeiten]
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)[Beantworten]

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

Commons: iOS-App zum Hochladen von Bildern

[Quelltext bearbeiten]
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)[Beantworten]

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][Beantworten]
  3. Kontra Dito. -- (Diskussion) 06:54, 22. Jun. 2017 (CEST)[Beantworten]
  4. Kontra Per 2 u. 3 -- Freddy2001 DISK 12:19, 24. Jun. 2017 (CEST)[Beantworten]
  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)[Beantworten]
  6. Pro --Thomas Obermair 4 (Diskussion) 17:16, 28. Jun. 2017 (CEST)[Beantworten]
  7. Pro --Morten Haan 🎲 Wikipedia ist für Leser daSkin-Entwurf 00:11, 29. Jun. 2017 (CEST)[Beantworten]
  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.[Beantworten]
  9. ProSDKmac (Disk., Bew.) 02:23, 30. Jun. 2017 (CEST)[Beantworten]
  10. Pro --Sebastian Wallroth 09:18, 1. Jul. 2017 (CEST)[Beantworten]
  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)[Beantworten]