Commons:Forum

From Wikimedia Commons, the free media repository
Jump to: navigation, search
Forum
Willkommen im Forum

Die Seite Forum soll als Diskussionsforum von Wikimedia Commons über Vorhaben, technische Fragen und Richtlinien dienen.

Alte Diskussionen finden sich im Archiv. Diskussionen, zu denen seit 14 Tagen keine Beiträge mehr verfasst wurden oder die seit 3 Tagen als erledigt (mittels {{Section resolved|1=~~~~}}) markiert sind, werden automatisch archiviert.

Bitte beachten:
  1. Falls du fragen möchtest, warum nicht-freies/kommerzielles Material bei Wikimedia Commons nicht erlaubt ist, müssen wir immer und ohne Ausnahme darauf verweisen, dass bei uns nur freier Inhalt erlaubt ist. Das ist eine in diesem Projekt unveränderliche Grundregel.
  2. Deine Frage könnte bei den häufig gestellten Fragen bereits beantwortet sein.
  3. Die Antworten, die du hier erhältst, sind keine Rechtsberatung und der Antwortende kann nicht verantwortlich gemacht werden. Bei rechtlichen Fragen können wir versuchen zu helfen, aber unsere Antworten können professionelle Hilfe nicht ersetzen.
Wo dir hier nicht geholfen wird:
  1. Bitte stelle hier keine Löschanträge. Um für eine Seite oder Datei einen Löschantrag zu stellen, nutze am besten einfach den Löschung-Vorschlagen Knopf, den Du auf der Seite, die gelöscht werden soll, in Deiner Werkzeugleiste findest.
  2. Für Diskussionen über Grafiken/Fotos/Karten/Videos/Töne besuche die Seite Graphics village pump.
  3. Für Verbesserungsanfragen von Grafiken (oder Grafikneuerstellungsanfragen), Fotos, Karten, Videos oder Tönen wende dich an die Grafik-, Foto-, Karten- oder Video- und Tonwerkstatt im Commons:Graphic Lab.
  4. Für Bilderwünsche besuche die Commons:Bilderwünsche
  5. Für Übersetzungswünsche besuche die Commons:Übersetzungswünsche
Diskussion (Verzeichnis)
Gnome User Speech.svg
Wichtige Diskussionsseiten

Centralized discussion

See also Commons:Village pump/Proposals

Please help by translating these messages into other languages.

Note: inactive discussions, closed or not, should be archived.

Archive  • Discussion • Edit • Page history • Watch




A propos "mobile upload"[edit]

Mobile Team will collect scrap. Phone now! ;-)
Mobile upload made easy!
Mit völlig sinnfreier Beschreibung und 100% gefälschten Exif-Daten hochgeladen. Es gab keine Rückfrage, ob es wirklich veröffentlicht werden solle.

A propos mobile upload: Das ist ja nicht mit anzusehen, gefühlte 95% selfies+URV (siehe User:Didym/Mobile_upload). Letzten Monat gab es ca. 6.000 Bilderuploads von mobilen Geräten und ca. 2.500 Löschungen. Und die mobilen Uploadzahlen steigen weiter... --Atlasowa (talk) 18:18, 7 May 2014 (UTC)

Zur Randbemerkung von Atlasowa: In der Tat. "Mobile Upload" klingt wohl für irgendwelche WMF-Leute cool und zeitgemäss, ist aber ein riesiger Schrottmagnet... hätte man auch ahnen können... Gestumblindi (talk) 22:16, 7 May 2014 (UTC)
A propos Schrottmagnet... --Atlasowa (talk) 09:59, 8 May 2014 (UTC)
Heh :-) Interessante Statistik. Mobile/Web uploads sollte man abschalten, da kommt wirklich fast nur Schrott rein. Seit Juli 2013: 34473 Uploads, davon bis Ende April 2014 22055 gelöscht. Also ca. 65% gelöscht. Die Löschquote scheint steigend zu sein: schaut man sich nur die Daten von Dezember 2013 bis April 2014 an, sind's 19071 Uploads, davon 13357 gelöscht (70%). In März wurde sogar mehr gelöscht als hochgeladen... Interessanterweise scheint die Quote bei den "native" IOS/Android Apps markant besser zu sein? Lupo 13:12, 8 May 2014 (UTC)
bugzilla:62598 könnte die Situation wenigstens etwas verbessern, aber auch dann wird da noch viel Schrott kommen. Momentan verbringe ich im Schnitt wahrscheinlich etwa eine halbe Stunde täglich nur damit, die URVs der mobile uploads zu löschen. --Didym (talk) 13:17, 8 May 2014 (UTC)
Hallo Didym! Alle Achtung für Deine fantastische Arbeit mit User:Didym/Mobile_upload und Commons:Deletion_requests/mobile_tracking! Eine Frage, wie erklärst Du Dir dass im April ca. 1.500 weniger mobile uploads gelöscht wurden als im Monat zuvor? Du wirst Dir doch nicht etwa eine kurze WikiPause erlaubt haben...? Tu das bloss nie wieder! ;-)) Oder siehst du einen anderen Grund? --Atlasowa (talk) 16:45, 8 May 2014 (UTC)
Mit einer halben Stunde kommt man nicht weit :-( Wir haben z.Z. über 13000 Bilder in Category:Uploaded_with_Mobile/Web. Ich hatte keine Probleme, nur schon auf der ersten Hälfte der ersten Seite mehrere Copyvios zu finden, z.T. schon vor längerer Zeit hochgeladen, also nicht erst gestern oder heute. Wenn man das zeitnah durchgehen kann (via Special:RecentChangesLinked/Category:Uploaded_with_Mobile/Web oder andere Tools), ist's einfacher. Je länger das Zeug bei uns herumliegt, um so schwieriger wird's, copyvios noch nachzuweisen. (Von den ganzen Selfies und anderem Müll will ich gar nicht erst anfangen.) Ob ein extra Bestätigungs-Dialog bei Uploads ohne EXIF da viel hilft, werden wir ja sehen. (Das scheint das Resultat von bugzilla:62598 zu sein : "Warning! This photo looks suspicious. If it's not a photo that you took, please do not upload it. Do you still want to continue?") Ich bin da skeptisch, diesen Uploadern ist das doch egal. Lupo 14:09, 8 May 2014 (UTC)
Genau diese Entwicklung haben wir vorhergesagt noch bevor dieser mobile-upload-Unsinn angeschaltet wurde, und natürlich ist es auch genauso eingetroffen. Was kümmerts die WMF, die müssen ja nicht täglich viele Stunden damit zubringen, den Müll wieder zu entsorgen. --Túrelio (talk) 14:12, 8 May 2014 (UTC)
Ich glaube wir sollten ein RFC (Meinungsbild) auf Commons starten um den mobile-upload für nicht "autopatrolled" user abzuschalten. --Steinsplitter (talk) 15:08, 8 May 2014 (UTC)
Wäre vielleicht einen Versuch wert. --Túrelio (talk) 06:37, 9 May 2014 (UTC)
Ich lese gerade, dass der bugfix zu bugzilla:62598 heute live gehen soll... Mal schauen wie sich das "user warnen" quantitativ (und qualitativ) auswirkt. --Atlasowa (talk) 17:39, 8 May 2014 (UTC)
Mal schauen wie sich die daily mobile uploads jetzt die nächsten Tage/Wochen entwickeln, der bugfix ("Show a confirm dialog when image has no EXIF data. Add browser tests too."[1]) sollte(?) ja am Donnerstag, 8. Mai live gehen. Ab 9. Mai scheint es einen Knick zu geben? Vgl. auch User:Didym/Mobile_upload/2014_May_9-12. Schaumermal. --Atlasowa (talk) 13:28, 11 May 2014 (UTC)
Übrigens, laut mw:UploadWizard "The newly formed Multimedia team is now planning to incrementally upgrade this tool in 2014, by fixing some longstanding bugs, as well as improve parts of the user experience and refactoring some of the code. This page will be expanded in coming weeks with more specific goals." und laut Commons:Multimedia_Features "The multimedia team is now focusing on these features this quarter (Jan.-March 2014): - Media Viewer, - UploadWizard". Ein besserer UploadWizard, endlich! Dabei fällt vielleicht auch was nützliches ab für die mobile uploads? Gibt es schon irgendwo eine "better UploadWizard" Wunschliste? --Atlasowa (talk) 17:48, 8 May 2014 (UTC)
Als erstes müsste der gesamte Code überarbeitet werden. Da ist ein Flickenteppich; taucht ein Problem auf und man versucht es zu beheben, wird irgendein anderer Bug sichtbar. Ich glaube aber nicht, dass viel für Mobile abfällt außer u.U. eines Hochlade-API-Moduls im Core. -- Rillke(q?) 20:15, 8 May 2014 (UTC)
Ein RFC zur Abschaltung dieses unsäglichen Features wäre wirklich angebracht. Oder, wie Steinsplitter oben vorschlug, nur noch für autoconfirmed accounts (falls wir das lokal so einrichten können). Ich habe mir diese mobile uploads in den letzten Wochen mal genauer angeschaut und konsequent SLAs auf alle copyvios/taken-from-web Bildchen gestellt. Wir kriegen da ca. 85% provable copyvios, 14% unused & unusable selfies. Das letzte Prozent enthält dann ein paar brauchbare Bilder. Durch die Bank weg sind alle Uploads als "own work"/cc-by-sa-3.0 markiert. Der Zeitaufwand, um die 99% Schrott zu entsorgen, ist beträchtlich und steht in keinem Verhältnis zur Anzahl brauchbarer Uploads. Irgendeine Verbesserung seit bugzilla:62598 konnte ich nicht feststellen. Lupo 22:42, 25 May 2014 (UTC)
Völlige zustimmung. Nur für autopatrolled user ;). Hatte mich schon des öfteren bei der WMF beschwert, das resultat nach Monaten war dieser lachhafte Filter. --Steinsplitter (talk) 22:52, 25 May 2014 (UTC)
Habe nun erneut eine Notiz hinterlassen. Ihr seid eingeladen den Bug zu kommentieren, bzw. +1 zu geben. RFC ist wirklich das Sinnvollste, habe das Gefühlt die WMF wird das Problem nicht beheben. --Steinsplitter (talk) 22:57, 25 May 2014 (UTC)
Nur mal so interessehalber: Hat denn mal jemand nachgeschaut, wie das technisch läuft? Läuft das nicht über den normalen Upload-Prozess, wie es ihn auch im Web gibt? Sollte dies der Fall sein, wird es wohl schwierig, mobile Uploads serverseitig zu beschränken. Grüße, --ChrisiPK (Talk|Contribs) 00:34, 26 May 2014 (UTC)
Indiz für meine Theorie: Special:ListGroupRights führt kein separates Recht für mobile Uploads auf. Grüße, --ChrisiPK (Talk|Contribs) 00:47, 26 May 2014 (UTC)
Ich denke es könnte reichen, wenn wir in der MediaWiki:Mobile.js code einbauen, der den Knopf auf Special:Uploads ausblendet. Aber vorher muss der Beschluss her. -- Rillke(q?) 01:38, 26 May 2014 (UTC)
Die Prozentzahlen (85%, 14%, 1%) sind nur geschätzt; ich habe nicht auch noch Strichlisten geführt. Ein besonderes Problem mit diesem mobile web upload ist, dass wir viele Instagram- und Twitter- Bildchen kriegen, die oft (a) nicht selbstgemacht sind, (b) relativ schwierig zu finden sind, (c) meist unbrauchbar sind. Bei Instagram kommt noch dazu, dass diese Bilder oft digital verfälscht sind. Eine andere Kategorie sind Smartphone screenshots, die irgendwelche Facebook/Twitter/Instagram-Bilder oder sonsige Websites zeigen. Gerne auch im Portrait-Format, mit dicken schwarzen Balken oben und unten. Generell macht es dies Web-Upload-Methode viel zu einfach, Bilder von irgendwelchen Websites hochzuladen. Viele der so hochgeladenen Bilder werden übrigens auch gar nicht verwendet. Es könnte also auch schon helfen, per Bot konsequent alles wegzulöschen, was eine Stunde nach dem Upload immer noch nicht verwendet wird. Ebenso alles, was ohne EXIF oder ohne EXIF mit übereinstimmender Bildgrösse daherkommt.
Mein Eindruck bei der ganzen Geschichte ist, dass die allermeisten Hochlader keine Ahnung haben, was sie da eigentlich tun. Weder ist ihnen bewusst, wofür die Bilder sein sollten, noch ist ihnen klar, dass es so etwas wie Urheberrecht gibt, noch haben sie kapiert, was eine "freie Lizenz" ist, noch scheren sie sich eine Dreck darum, dass Wkipedia "frei" sein sollte. Ich bin mir auch nicht sicher, ob sie die Warnungen auf ihrer Diskussionsseite überhaupt je sehen. Falls die Warnung von bugzilla:62598 tatsächlich angezeigt wird, wird sie einfach weggeklickt, so wie man ja auch z.B. die Samsung/Apple Geschäftsbedingungen bei Software-Updates einfach ohne zu lesen wegklickt.
Übrigens ist es wichtig, dass diese Uploads zeitnah überprüft werden. Liegt der Schrott erst einmal ein paar Monate hier herum, wird es ungleich schwieriger, eine copyvio nachzuweisen. Ist ja logisch: finde ich das Bildchen gleich nach dem Upload irgendwo sonst wieder, kann ich davon ausgehen, dass es von dort geklaut wurde. Liegt das Bild aber schon seit 2013 hier, muss ich erst einmal eine externe Verwendung des Bildes vor dem Hochladezeitpunkt finden, um sicher sagen zu können, dass das Bild vor dort hierher kopiert wurde (und nicht umgekehrt).
Vielleicht sollte man auch einfach {{Uploaded from Mobile|platform=Web}} in {{speedy|reason=Uploaded from Mobile/Web}} umbauen. ;-/ Lupo 06:12, 26 May 2014 (UTC)
  • Per bugzilla:62598#c37, they're going to try restricting the Mobile/Web upload to autoconfirmed users. Lupo 19:13, 27 May 2014 (UTC)
Gut. Hatte mich vorhin noch etwas im IRC beschwert und den Projectmaneger in CC genommen. Ich sehe atm noch keinen Patch dazu, wird aber vermutlich noch etwas dauern. --Steinsplitter (talk) 19:34, 27 May 2014 (UTC)
Ich hoffe, das kommt bald. Im Mai hatten wir via Mobile/Web 5570 Uploads (+27% seit April) und 4085 Löschungen, wobei da wohl Einiges noch in den COM:DEL- und "No permission"-Pipelines steckt. In Juni sind bis jetzt 296 Uploads und 380 Löschungen registriert. Lupo 12:45, 2 June 2014 (UTC)
(gerrit:137461) Only show upload icon to autoconfirmed users. - Wird bald auf Commons eingespielt. --Steinsplitter (talk) 17:28, 5 June 2014 (UTC)

Vielen Dank an Steinsplitter, Lupo und auch Rillke fürs Nachhaken auf bugzilla! Ich hoffe wir werden bald eine wesentlich gesündere Entwicklung sehen. :-) --Atlasowa (talk) 21:55, 14 June 2014 (UTC)

Ich weiss zwar nicht genau, ob bugzilla:62598 nun aktiv ist, aber da die später gemachten Änderungen aus bugzilla:66169 mittlerweile aktiv sind, vermute ich 'mal, dass auch die "autoconfirmed"-Änderung nun "live" ist. Ich kann jedoch keinerlei Verbesserung feststellen. Wir kriegen nach wie vor fast ausschliesslich Schrott via Special:RecentChangesLinked/Category:Uploaded_with_Mobile/Web. Lupo 15:10, 29 June 2014 (UTC)
Ich habe da momentan kein Auge drauf: Ist es denn wenigstens zahlenmäßig weniger geworden? --El Grafo (talk) 11:51, 30 June 2014 (UTC)
Nein. Gleichbleibend viele uploads, gleichbleibend lausiger retention factor. Lupo 17:05, 30 June 2014 (UTC)
Dann sollten wir mobile uploads nur von autopatrolled usern zulassen. :/ --Steinsplitter (talk) 17:33, 30 June 2014 (UTC)
Hm, Autopatrolled user wären gerade mal ca. 3.500 von Hand Auserwählte Benutzer...
Mobile Uploads per month
Mobile Uploads per day
User:Didym/Mobile upload
Im März hiess es noch von kenan wang auf bugzilla: "We're also doing analysis as to what call to actions produce more deleted images, that way we can also analyze UI level fixes to this issue." - Ist da irgendwas raus geworden? Kann man das irgendwo nachlesen?
Im Mai sagt Juliusz Gonera: "Sorry for not replying here in a long time. There was a change of product manager in the mobile team which slowed things down and made us lose focus." - Meanwhile on commons...
Und User:Maryana (WMF): "It was good to try the EXIF filter for combatting low quality uploads, but it seems pretty clear that this isn't the right strategy for dealing with the issue. (...) We're going to try limiting mobile web uploading to autoconfirmed users, which should drastically lower the volume of incoming uploads (...) As always, thanks for the feedback; we'll continue to monitor the feature..."
Und Maryana Pinchuk gestern: Ja, das autoconfirmed-limit ist live, aber "I wanted a bit of time to go by before digging into the data, since deletion doesn't always happen immediately post upload -- I can run some stats on uploads & deletions from before and after the change went live and share with you. Keep in mind, however, that we recently (since June 17) began redirecting users on tablets to the mobile site (they'd previously been going to the desktop site), which appears to have increased the number of new mobile editors and uploaders, so while the ratio of good-to-bad uploads may have changed, the absolute numbers of both have probably gone up. I'll dig into the data on that, too."
Suuuper. Besonders toll: Die Analyse scheint davon auszugehen, dass, wenn nur 80% der mobile-web-uploads auf commons gelöscht werden, umgekehrt 20% useful sind. Wenn wegen Überlastung nur noch 50% der Schrottflut gesichtet und gelöscht werden, dann ist das also ein Erfolg, weil dann ja 50% useful sind ...? ^^
Wie wäre es denn mit folgendem Vorschlag: Wir lassen einen Bot automatisch jeden mobile-web-upload mit metadaten per email ans WMF mobile team schicken und automatisch auf commons schnelllöschen. Dann kann das mobile team so ganz in Ruhe über Monate seine "Analysen" machen (Wieviel sind selfies, URV, sonstiger Schrott? / Wieviel Zeit verschwendet man mit dem Müllsortieren? / Nach wievielen Genitalfotos hat man keinen Bock mehr hinzusehen? / analyze UI level fixes? / Könnte man diese Arbeit womöglich durch tools vereinfachen? usw.) Und geben uns dann danach eine Liste mit den 5 tatsächlich brauchbaren mobile-web-uploads, dann kann ein admin die bei commons wiederherstellen. Und alle sind glücklich. Deal? --Atlasowa (talk) 11:56, 1 July 2014 (UTC)
Re Die Analyse scheint davon auszugehen, dass, wenn nur 80% der mobile-web-uploads auf commons gelöscht werden, umgekehrt 20% useful sind. Wenn wegen Überlastung nur noch 50% der Schrottflut gesichtet und gelöscht werden, dann ist das also ein Erfolg, weil dann ja 50% useful sind ...?: diesen Eindruck habe ich leider auch. Lupo 20:04, 2 July 2014 (UTC)

Upload-Logs[edit]

Pictogram voting info.svg Info Eine weiterer Versuch, die mobilen uploads auf Nutzer mit Status autoconfirmed zu beschränken sollte heute live gehen: bugzilla:62598#c60 --El Grafo (talk) 14:22, 10 July 2014 (UTC)
OK, die gute Nachricht: Im Moment sieht es so aus als würden sich die mobile-web uploads halbieren: Mobile Uploads per day. Das sieht wirklich schon viel besser aus.
Die schlechte Nachricht: Die mobile-web Uploads werden aber weiter steigen und es gibt immernoch einen großen Teil URV und Selfies (vgl. User:Didym/Mobile upload/2014 July 9-12). Ich befürchte, dass WMF das Problem damit für erledigt hält (der Rest ist ein "community problem"?). Ich erwarte eigentlich von WMF, dass sie diese Atempause nutzen, um endlich nachhaltige Änderungen, tools und UI-fixes vorzubereiten. Also:
1) Eine Analyse des letzten Jahres mit mobile-web uploads: Wieviel uploads von nicht-autoconfirmed Benutzern und Löschquote, wieviel uploads von autoconfirmed-Benutzern und Löschquote, wieviel uploads von autopatrolled Benutzern und Löschquote? Damit hier bei weiter steigender Bilderflut nicht wieder so ewig rumgestümpert wird.
2) Eine Analyse des letzten Jahres mit mobile-web uploads: Wieviel uploads via "in-article upload button" und Löschquote? Wieviele landen tatsächlich dauerhaft in Wikipedia-Artikeln (und sind keine URV)? Vielleicht identifizierte Schrottmagneten einfach mal abschalten?!
3) Einen brauchbaren Upload Wizard! Für Desktop und mobile. Mit Kategorisierungsvorschlägen... (ich sehe ständig uploads von WMF-Benutzern, die ihre eigenen screenshots nicht kategorisieren... wollen/können?) Wie wäre es bspw. mit einem vorgeschalteten Commons-erklärenden Video-Tutorial für brandneue Uploader?
4) Andere Bilder-Hosts benutzen Bilderkennungssoftware: Gesichtserkennung (= wahrscheinlich ein menschliches Gesicht, nicht: welches Gesicht), Texterkennung (OCR), Erkennung von Grafiken vs. Fotos, Dubletten/URV-erkennung (tineye, google images). Das kann enorm helfen und Zeit sparen bei der (weiterhin: menschlichen!) Überprüfung.
Die sogenannte "Selfie-pocalypse" haben wir jetzt seit über einem Jahr. Siehe die gleichen Diskussionen hier und hier usw. Warum haben wir den jetzigen fix nicht schon vor einem Jahr bekommen? Wie geht das weiter? --Atlasowa (talk) 12:03, 13 July 2014 (UTC)
Das scheint tatsächlich in etwa die Anzahl Uploads via Mobile/Web etwa halbiert zu haben. Habe mir das gestern 'mal genauer angeschaut, allerdings nur für den gestrigen Tag:
Auffällig ist, wenn man das mit Uploads vor dem 10. Juli vergleicht, dass keine Instagam-Uploads mehr dabei sind, und die Anzahl Selfies stark reduziert ist. Hingegen haben wir immer noch überwiegend URVs die einfach von irgendwelchen Websites kopiert (und dann hier per SLA gelöscht) wurden.
Die bisherigen Massnahmen aus bugzilla:62598 haben zwar etwas geholfen indem die Gesamtzahl der Uploads reduziert wurde und einige Problemuploads nun gar nicht mehr erst gemacht werden; jedoch sind die Massnahmen weiterhin unzureichend. Mobile/Web-Uploads leiden immer noch unter dem gleichen systemischen Problem: die Benutzer dieses Features haben keinen blassen Schimmer von Urheberrechten, freien Lizenzen, oder von Commons.
Summa summarum: von 87 Uploads bleiben ganze vier, die brauchbar und "in scope" sind. Das ist eine Erfolgsrate von unter 5%! Oder anders herum: 95% ist immer noch Schrott.
Lupo 08:11, 17 July 2014 (UTC)
Danke, Lupo, für die Analyse – das deckt sich mit meinem persönlichen Eindruck. Ich widerhole mal den Kernsatz: [D]ie Benutzer dieses Features haben keinen blassen Schimmer von Urheberrechten, freien Lizenzen, oder von Commons.
Unter diesem Gesichtspunkt halte ich die Multimedia Vision 2016 zumindest in Teilen für sehr bedenkenswert. (Dass keine der verbliebenen Dateien auch nur eine einzige Nicht-Wartungskategorie hat, ist da fast schon nebensächlich.) --El Grafo (talk) 08:34, 17 July 2014 (UTC)
  • 16. Juli 2014: siehe oben.
    Am 28. Juli 2014 noch vorhanden: 14, davon 10-11 unbenutzte Selfies. Lupo 08:07, 28 July 2014 (UTC)
  • 17. Juli 2014: 84 Uploads. Davon jetzt noch 44 vorhanden. Davon 6 "no permission", 5 mit Löschanträgen, 7 Selfies oder selfie-like. Bleiben 26: 70% Müll ist etwas besser als gestern, aber immer noch lausig. Zumal mir die Uploads von User:Meneaki1283 zum Teil fragwürdig scheinen (einige lassen sich auf Baidu finden), und bei den Uploads von User:欣之介 bin ich mir auch nicht sicher, ob das alles selbstgemachte Fotos sind oder evtl. Fotos von Fotos oder gar TV screengrabs. Lupo 21:51, 18 July 2014 (UTC)
    Am 28. Juli 2014 noch vorhanden: 20, davon 1 Löschantrag und 3 unbenutzte Selfies. Lupo 08:07, 28 July 2014 (UTC)
  • 18. Juli 2014: 91 Uploads, davon jetzt noch 44 vorhanden. Davon 10 "no permission", 7 Löschanträge, 5 Selfies, 1 "no source", 1 copyvio SLA. Bleiben 20, wovon 10 nicht gerade nützlich (subjektiv: Katze, faked(?) Signature of Taylor Swift, unused ugly "fashion model", Logo, so was, ...). Also etwa 11% OK, 89% Schrott. Lupo 11:00, 19 July 2014 (UTC)
Und dann scheint manch einer noch nichtmal zu wissen, wo er ist :-) --Magnus (talk) 11:54, 19 July 2014 (UTC)
Am 28. Juli noch vorhanden: 24, davon 4 unbenutzte Selfies und 1 Löschantrag. Lupo 08:07, 28 July 2014 (UTC)
  • 19. Juli 2014: 123 Uploads. Davon jetzt noch 42 vorhanden. Davon 9 "no permission", 6 Löschanträge, 3 "no source"/"no license", 10 Selfies. Bleiben 14, wovon mndestens vier subjektiv unnütz sind. Bleiben etwa 10 brauchbare, d.h. etwa 8% OK, 92% Schrott. Feedback in Bugzilla. Lupo 11:19, 20 July 2014 (UTC)
Am 5. August noch vorhanden: 23, davon 10 unbenutzte Selfies oder Selfie-like Bildchen. Lupo 18:51, 5 August 2014 (UTC)
  • 20. Juli 2014: 104 Uploads. Davon jetzt noch vorhanden 40. Davon 7 "no permission" (ein Release für das hier wäre toll), 10 reguläre Löschanträge (wovon einer evtl. zu behalten wäre), 2 "no source", 5 copyvio SLA, 5 selfies, und zwei weitere subjektiv unnütz (dies und das). Bleiben 10, also etwa 10% OK, 90% Schrott. Wie lange soll das so weitergehen? Wenn ich der WMF doch nur meine Zeit zu meinem üblichen Stundensatz in Rechnung stellen könnte... dann würden diese blödsinnigen Uploads wohl rasch abgestellt. :-/ Lupo 10:41, 21 July 2014 (UTC)
Am 5. August noch vorhanden: 15, davon 9 unbenutzte Selfies. Lupo 18:55, 5 August 2014 (UTC)
  • 21. Juli 2014: 96 Uploads. Davon jetzt noch vorhanden 42. Davon 9 "no permission", 10 Löschanträge, 3 "no source"/"no license", 3 copyvio SLA, 7 Selfies, 4 subjektiv unnütz (digital verfälscht; keine Info, Logo). Bleiben 6: etwa 6% OK, 94% Schrott. Lupo 07:46, 22 July 2014 (UTC)
Am 5. August noch vorhanden: 16, davon 9 unbenutzte Selfies. Lupo 18:58, 5 August 2014 (UTC)
  • 22. Juli 2014: 78 Uploads. Davon jetzt noch vorhanden 40. Davon 19 "no permission", 2 Löschanträge, 1 "no source", 4 Selfies, und 1 subjektiv unnütz (das da). Bleiben 13: ca 16% OK, 84% Schrott. Lupo 07:16, 23 July 2014 (UTC)
Am 6. August noch vorhanden: 17, davon 5 unbenutzte Selfies. Lupo 07:20, 6 August 2014 (UTC)
  • 23. Juli 2014: 85 Uploads. Davon jetzt noch vorhanden 51. Davon 6 "no permission", 4 Löschanträge, 1 "no source", 2 copyvio SLA, 23 Selfies oder selfie-like, die meisten von diesen werden unbenutzt bleiben und irgenwann als "out of scope: unused personal photos of non-notable person" gelöscht werden (oder auch nicht: unnütz sind die meisten davon dennoch). Bleiben 15 (von denen einige aber nicht über alle Zweifel erhaben sind): ca 17% OK, 83% Schrott. Lupo 06:07, 24 July 2014 (UTC)
Am 6. August noch vorhanden: 37, davon 16 unbenutzte Selfies. Lupo 07:20, 6 August 2014 (UTC)
  • 24. Juli 2014: 80 Uploads. Davon jetzt noch vorhanden 46. Davon 4 "no permission", 1 Selfie, und 1 "fair use delete". Bleiben 40. Ergibt 50% OK, 50% Schrott. Lupo 06:45, 25 July 2014 (UTC)
    Allerdings habe ich an diesem Tag zum ersten Mal in drei Monaten einen erfahrenen Benutzer gesehen, der dieses Feature verwendet hat, und zwar so, wie's gedacht ist: er hat 28 selbstgemachte Bilder hochgeladen. Wenn wir nur die Uploads der anderen (unerfahrenen) Benutzer anschauen, ergibt das 52 Uploads von unerfahrenen Benutzern, davon noch vorhanden 18, davon 4 "no permission", 1 Selfie, 1 fair use delete: bleiben 12: 23% OK. So oder so: dies ist der erste Tag, an dem wirklich nur noch "autoconfirmed" Benutzer das Feature benutzen konnten (bugzilla:68414 geflickt). Deshalb weniger Uploads, und auch prozentual leicht besser. Mal schauen, wie das weiter geht. Lupo 06:45, 25 July 2014 (UTC)
Am 6. August noch vorhanden: 41, d.h. 13 von unerfahrenen Benutzern. Lupo 07:20, 6 August 2014 (UTC)
  • 25. Juli 2014: 47 Uploads. Davon jetzt noch vorhanden 15. Davon 2 "no permission", 2 Löschanträge, 1 "no source". Bleiben 10: 21% OK, 79% Schrott. Lupo 17:04, 27 July 2014 (UTC)
Am 6. August noch vorhanden: 10, davon 1 Löschantrag. Lupo 07:20, 6 August 2014 (UTC)
  • 26. Juli 2014: 61 Uploads. Davon jetzt noch vorhanden 18. Davon 4 "no permission", 4 Löschanträge, 3 copyvio SLA. Bleiben 7: 11% OK, 89% Schrott. Lupo 17:04, 27 July 2014 (UTC)
Am 6. August noch vorhanden: 9, davon 2 Löschanträge. Lupo 07:20, 6 August 2014 (UTC)
  • 27. Juli 2014: 49 Uploads. Davon jetzt noch vorhanden 20. Davon 2 "no permission", 1 Löschantrag, 2 "no source", 5 copyvio SLA, 7 Selfies, 1 unnützes und unbenutztes selbstgebasteltes Logo: bleiben 2. 4% OK, 96% Schrott. (Wenn die zwei "no source" noch Quellenangaben bekommen, 4, d.h. 8%.) Lupo 07:14, 28 July 2014 (UTC)
Am 6. August noch vorhanden: 10, davon 4 unbenutzte Selfies. Lupo 07:20, 6 August 2014 (UTC)
  • 28. Juli 2014: 62 Uploads. Davon jetzt noch vorhanden 32. Davon 5 "no permission", 2 Löschanträge, 3 "no source", 10 Selfies: bleiben 12, darunter keinerlei Info (wo ist das?) und fragwürdig (vgl. Upload-Log at en:File:Visioncabo.jpg: Beschreibung und Lizenz gelten für den ersten Upload von 2006, nicht für die darübergeladene Datei von 2009). Na ja: 12 Dateien ergibt 19% OK, 81% Schrott. Lupo 08:29, 29 July 2014 (UTC)
    Interessant übrigens das da: "bad" Upload einer low-res-Datei, die dann im Original auf Flickr gefunden wurde (und sogar eine akzeptable Lizenz hat). Sieht man auch ab und zu; dies ist nicht das erste Mal, dass das vorkommt. Meist allerdings sind die Flickr-Dateien in solchen Fällen leider nicht frei lizenziert. Kommt übrigens noch häufiger mit panoramio-Bildern vor; vermutlich weil diese auf Google Maps/Earth angezeigt werden. Diese sind jedoch noch seltener frei lizenziert. Lupo 08:29, 29 July 2014 (UTC)
  • 29. Juli 2014: 46 Uploads. Davon jetzt noch vorhanden 28. Davon 2 copyvio SLA, 5 "no permission", 2 "no source", 6 selfies (davon 1, das wie ein Film/TV screengrab aussieht), 3 Löschanträge, sowie 2 re-uploads, die reverted wurden. Bleiben 18, davon 2 fotos von alten Fotos. 18/46 = 39% ±OK, 61% Schrott. Lupo 07:47, 30 July 2014 (UTC)
So, noch mal ein kurzes Update: Wie im Bugreport zu lesen war, hat sich das Mobile Web Team entschieden, den Patch doch noch auf wmf15 zu backporten, was bedeutet, dass dieser heute (also am 29. Juli) mit dem Deployment von MW 1.24wmf15 auf Commons aufgespielt werden wird. Allerdings hat das logischerweise noch keine Auswirkung auf den Upload, da der Standadwert für die Uploadbegrenzung bei 0 dits liegt. Hierfür gibt es diesen Patch, welcher den minimum Editcount für Commons auf 75 anheben würde. Muss nu noch reviewed und gemerged werden :) Grüße --194.114.62.123 07:30, 29 July 2014 (UTC) Hhm, war wohl abgemeldet :( Der Beitrag kommt von mir --Florianschmidtwelzow (talk) 10:05, 29 July 2014 (UTC)
Ich dachte, diese Restriktion wäre für "local edit count"? Verwenden die meisten Benutzer das nicht von den Wikipedias aus, so dass dieses Limit von 75 gar nicht greift? Ich würde den default auf 10 oder 20 setzen. (10 entspricht der Einstellung für "autoconfirmed" auf en-WP, aber von dort kommt, soweit ich sehe, immer noch ziemlich viel Unbrauchbares. Ich schlage vor, wir fangen 'mal mit 10 an, und wenn das noch nicht die gewünschte Verbesserung bringt probieren wir 20 als default.) Lupo 21:45, 29 July 2014 (UTC)
Exakt, damit ist der local edit count gemeint. Auf Vorschlag von Ryan Kaldari habe ich im Patch für die Konfiguration des minimum editcount einen Defaultwert von 10 (für alle WMF-Wikis außer Commons), sowie für Commons von 75 eingetragen. Inwieweit diese Grenzen ausreichend sind, wird sich hoffentlich schnell zeigen, lassen sich aber auch "easy" anpassen. Grüße --Florianschmidtwelzow (talk) 05:13, 30 July 2014 (UTC)
Bis jetzt kann ich keinen signifikanten Effekt feststellen. Lupo 09:30, 5 August 2014 (UTC)
  • 30. Juli 2014: 41 Uploads. Davon jetzt noch vorhanden 12; davon 3 "no permission", 1 Löschantrag, 3 Selfies. Bleiben 5: ca. 12% OK, 88% Schrott. Lupo 09:30, 5 August 2014 (UTC)
  • 31. Juli 2014: 70 Uploads. Davon jetzt noch vorhanden 33; davon 9 Löschanträge und 7 Selfies. Bleiben 17: 24% OK, 76% Schrott. Lupo 09:30, 5 August 2014 (UTC)
  • 1. August 2014: 60 Uploads. Davon jetzt noch vorhanden 28; davon 2 "no permission", 7 Löschanträge, 4 Selfies. Bleiben 13: ca. 21% OK, 79% Schrott. Lupo 09:30, 5 August 2014 (UTC)
  • 2. August 2014: 29 Uploads. Davon jetzt noch vorhanden 13, davon 1 "no permission", 5 Löschanträge, 1 "no source", 2 Selfies. Bleiben 4: 13% OK, 87% Schrott. Lupo 09:30, 5 August 2014 (UTC)
  • 3. August 2014: 53 Uploads. Davon jetzt noch vorhanden 21, davon 2 copyvio SLA, 4 "no permission", 1 "no source", 2 Löschanträge, 4 Selfies. Bleiben 8: 15% ±OK, 85% Schrott. Lupo 10:42, 5 August 2014 (UTC)
  • 4. August 2014: 70 Uploads. Davon jetzt noch vorhanden: 31. Davon 3 "no license", 2 "no permission", 3 Löschanträge, 1 copyvio SLA, 1 Selfy. Bleiben 21: 30% ±OK, 70% Schrott. In den 30% gibt es aber ein paar unnütze oder fragwürdige Dateien. Lupo 14:01, 5 August 2014 (UTC)
  • 5. August 2014: 45 Uploads. Davon jetzt noch vorhanden: 20. Davon 1 "no license", 5 "no permission", 2 Selfies. Bleiben 12 (2 subjektiv unnütz): 26% ±OK, 74% Schrott. Lupo 06:36, 6 August 2014 (UTC)
  • 6. August 2014: 46 Uploads. Davon jetzt noch vorhanden 16. Davon 3 "no permission", 1 Löschantrag, 1 copyvio SLA, 7 Selfies. Bleiben 4: ca. 8% ±OK, 92% Schrott. Allerdings sind von den 4 verbliebenen drei selbstgebastelte Logos (wovon 2 nahezu identisch) die m.E. "out of scope" sind. Bleibt also eigentlich nur gerade ein einziges halbwegs brauchbares Bildchen, und selbst das ist ein Textlogo und kein selbstgemachtes Foto! (1 Bild von 46 ergäbe dann 2% ±OK, 98% Schrott.) Ich warte nur noch auf den Tag, an dem gar kein brauchbares Bild übrigbleibt... Lupo 06:48, 7 August 2014 (UTC)
Was mich auch sehr wundert, bei diesem Bild, dass der User laut CentralAuth keine der Kriterien erfüllt um Special:Uploads mobil auf irgendeiner Wikimedia-Wiki zu nutzen. Ich habe gerade mal bei mir getestet und wenn ich Special:Uploads auf en.wiki aufrufe (wo ich weder autoconfirmed bin, noch 10 edits habe) kann ich ein Bild beitragen, was so keineswegs gewollt ist. Da müssen wir definitiv noch mal nachbessern. --Florianschmidtwelzow (talk) 15:15, 7 August 2014 (UTC)
Danke, Florian, dass auch Du dranbleibst. Ich hatte schon in bugzilla:62598#c151 einen solchen Fall beschrieben. Wurde leider gleich wieder geschlossen, weil ich fälschlicherweise dachte, Gerrit 150145 sei schon deployed und geschrieben hatte, das funktioniere nicht richtig. Lupo 19:28, 7 August 2014 (UTC)
Diesen reopen hatte ich auch gesehen und war ebenfalls der Meinung wie MaxSem, was, wie wir jetzt wissen, falsch war :) Nur noch kurz zur Info: Ich gehe davon aus, dass der Patchset, den ich bereits oben verlinkt habe, so auch germerged wird (ggf. noch kleine Designanpassungen). Kann sich allerdings noch etwas ziehen wegen Wikimania und so :D Grüße --Florianschmidtwelzow (talk) 21:48, 10 August 2014 (UTC)
Hallo nochmal! Wie sicher bereits bemerkt, wurde der Patch jetzt germerged. Montag geht's dann daran, diesen auf wmf17 zu backporten, was vermutlich (nach meiner derzeitigen, persönlichen Planung) im Wartungsfenster am Dienstag geschehen wird und anschließend auch auf Commons und allen anderen Wikimedia Wikis (am Mittwoch deutscher Zeit) angewandt werden sollte. --Florianschmidtwelzow (talk) 21:19, 16 August 2014 (UTC)
Und schon wieder ich :) Wie erwartet wurden die Patches (bzw. der für hier relevante Patch) gestern (bzw. heute, je nachdem nach welcher zeit), auf die aktuelle wmf17 Version geported. Auf Commons, wikivoyage und anderen group1 wikis der Wikimedia foundation ist der patch bereits ausgerollt (da diese schon auf wmf17 sind), auf die Wikipedia wikis wird er voraussichtlich am morgigen Donnerstag mitsamt dem Update auf MW1.24wmf17 verteilt werden. Freue mich schon auf die Veränderungen. Grüße --Florianschmidtwelzow (talk) 00:19, 20 August 2014 (UTC)
@Florianschmidtwelzow: Das ist der zur Zeit letzte noch ausstehende Patch für dieses Problem, richtig? Lupo 06:02, 20 August 2014 (UTC)
@Lupo: Exakt, zumindest was die Deaktivierung der Uploadfunktion betrifft. Wie man die Qualität der Uploads aus dem mobile Web allgemein verbessern kann, wird dann irgendwann in Zukunft folgen (hoffe ich :P). Aber das steht ja auf einem anderen Papier. --Florianschmidtwelzow (talk) 18:38, 20 August 2014 (UTC)
  • 7. August 2014: 49 Uploads (die vier Reverts in File:Long black hair.jpg nicht gezählt). Davon jetzt noch vorhanden: 18, davon 5 "no permission", 2 Löschanträge, 1 copyvio SLA, 6 Selfies. Bleiben 4, davon 1 Textlogo: 8% ±OK, 92% Schrott. Lupo 06:00, 8 August 2014 (UTC)
  • 8. August 2014: 41 Uploads (Doppel-Upload von File:Carlo González.jpeg nur ein Mal gezählt). Davon jetzt noch vorhanden: 17. Davon 2 "no permission", 1 Löschantrag, 1 "no license", 7 Selfies oder Selfie-like. Bleiben 6: 14% ±OK, 86% Schrott. Lupo 21:38, 9 August 2014 (UTC)
  • 9. August 2014: 69 Uploads. Davon jetzt noch vorhanden 34. Davon 4 "no permission", 1 Löschantrag (evtl. zu behalten), 2 Selfies. Bleiben 27: 39% ±OK, 61% Schrott. Danke, User:Btcpg! Lupo 13:10, 10 August 2014 (UTC)
  • 10. August 2014: 90 Uploads (12 Reverts von Fussball-Trikot-Kits nicht gezählt, da diese nicht durch Mobile/Web upload gingen). Davon jetzt noch vorhanden 45. Davon 5 "no permission", 1 Löschantrag, 1 "no source", 7 Selfies oder Selfie-like, 1 copyvio SLA. Zwei Benutzer, die das Feature so verwenden, wie's gedacht ist und die mehrere Dateien hochgeladen haben: User:Btcpg und User:Owais khursheed. Beides keine Neulinge. Dank ihnen ist die Statistik besser als auch schon (aber immer noch ziemlich schlecht): bleiben 30 Bilder: 33% ±OK, 67% Schrott. Lupo 05:32, 11 August 2014 (UTC)
  • 11. August 2014: 66 Uploads (7 Fussball-Trikot-Reverts nicht gezählt). Davon jetzt noch vorhanden: 30. Davon 5 "no permission", 2 Löschanträge, 1 "no license", 5 Selfies oder Selfie-like. Bleiben 17: 25% ±OK, 75% Schrott. Lupo 05:06, 12 August 2014 (UTC)
  • 12. August 2014: 50 Uploads. Davon jetzt noch vorhanden 26. Davon 2 "no permission", 2 Löschanträge, 4 Selfies. Bleiben 18, davon 2 Mobile screenshots (unnütz, aber der Benutzer fand's wohl einfacher, screenshots zu posten statt einen kurzen Text auf pl:Dyskusja:Prawda_(gazeta) zu schreiben um das Problem (falsche Person verlinkt) zu erklären) und 2 Kronen, die ich eigentlich nicht für "own work" halte sondern von irgendwo her kopiert. Na ja: 18/50 ergibt 36% ±OK, 64% Schrott. Lupo 08:26, 13 August 2014 (UTC)
  • 13. August 2014: 56 Uploads. Davon jetzt noch vorhanden 16. Davon 3 "no permission" und 9 Selfies oder selfie-like. Bleiben 4: 7% ±OK, 93% Schrott. Lupo 05:48, 14 August 2014 (UTC)
  • 14. August 2014: 35 Uploads (2 reverts bei File:Gola camiseta polo aberta.png nicht gezählt). Davon jetzt noch vorhanden 17. Davon 5 "no permission", 2 Löschanträge, 2 Selfies, 1 copyvio SLA. Bleiben 7, wovon einige aber zweifelhaft bzw. unnütz sind. 7/35 = 20% ±OK, 80% Schrott. Lupo 07:36, 15 August 2014 (UTC)
  • 15. August 2014: 34 Uploads. Davon jetzt noch vorhanden 13 (das hier wurde hierher verschoben). Davon 3 "no permission", 1 Löschantrag, 3 Selfies, 2 copyvio SLA. Bleiben 4: 11% ±OK, 89% Schrott. Lupo 11:15, 16 August 2014 (UTC)
  • 16. August 2014: 48 Uploads. Davon jetzt noch vorhanden 22. Davon 7 Löschanträge, 1 "no permission", 1 "no source", 3 Selfies. Bleiben 10: 20% ±OK, 80% Schrott. Lupo 08:49, 17 August 2014 (UTC)
  • 17. August 2014: 56 Uploads. Davon jetzt noch vorhanden 14. Davon 2 "no permission", 1 Löschantrag, 1 copyvio SLA, 2 Selfies. Bleiben 8: 14% ±OK, 86% Schrott. Lupo 07:25, 18 August 2014 (UTC)
  • 18. August 2014: 70 Uploads. Davon jetzt noch vorhanden: 41. Davon 6 "no permission", 13 Löschanträge, 5 copyvio SLA, 3 Selfies. Bleiben 14: 20% ±OK, 80% Schrott. Lupo 06:24, 19 August 2014 (UTC)
  • 19. August 2014: 55 Uploads. Davon jetzt noch vorhanden 27. Davon 4 "no permission", 2 Löschanträge (evtl. zu behalten), 2 "no source", 8 Selfies. Bleiben 9: 16% ±OK, 84% Schrott. Lupo 06:02, 20 August 2014 (UTC)
  • 20. August 2014: 58 Uploads (7 Fussball-Trikot-Reverts nicht gezählt). Davon jetzt noch vorhanden: 17. Davon 3 "no source", 2 "no permission", 1 Löschantrag, 2 Selfies. Bleiben 9: 15% ±OK, 85% Schrott. Lupo 06:50, 21 August 2014 (UTC)


Duplikate[edit]

Bekommen die mobilen Nutzer eigentlich ein Warnung wenn hochzuladene Dateien schon vorhanden sind? Ich hatte letztens viele Duplikate gelöscht die mobil hochgeladen wurden. --Denniss (talk) 08:28, 17 July 2014 (UTC)

Zurzeit offenbar nicht. Allerdings, so mein lokaler Test und der Quellcode, wird als Dateiname das bereits vorhandene Bild verwendet. Würde also maximal als neue Version hochgeladen, i.d.R. aber gar nicht neu hochgeladen. Hier wäre ggf. eine Warnmeldung deutlich effektiver. --Florianschmidtwelzow (talk) 13:25, 20 July 2014 (UTC)
Meine Frage zielte auf Bilder die under anderem Dateinamen hochgeladen werden sollen aber bereits in identischer Form existieren. Dies betrifft ggf auch andere Uploadprogramme wie Vicuania usw die identische Duplikate scheinbar ohne Warnung hochladen dürfen. --Denniss (talk) 11:31, 21 July 2014 (UTC)
Das scheint überhaupt nicht zu funktionieren. Siehe File:The first sale UPC made was made in a water bottle 2014-07-20 19-45.jpg und File:UPCs most recent sale 2014-07-20 15-38.jpg. Am gleichen Tag hochgeladen, vom gleichen Benutzer, und soweit ich das erkennen kann absolut identisch. Wurden auch auf den Dateibeschreibungsseiten heute Morgen nicht als Duplikate angezeigt. Was auch recht häufig vorkommt: low-res JPGs von Dateien, die wir schon in höherer Auflösung haben. (Beispiel: Neu-upload File:Old shrewsbury town badge 2014-07-20 23-35.jpg und bestehende Datei File:Shrewsbury Town Loggerheads Crest.png.) Lupo 10:48, 21 July 2014 (UTC)
Die Dublikate wurden ja bereits gelöscht, sodass ich da leider nicht mehr direkt mit den Bildern testen kann (wenn du die noch direkt herunterladen kannst ohne die wiederherstellen zu müssen, kannst du mir die gerne, wenn du möchtest, an meine Bugzilla-E-Mailadresse schicken (User: Florian, sollte ja bekannt sein)). Allerdings habe ich lokal mit zwei identischen Bildern den Upload versucht und das Bild wurde, wie ich oben geschrieben habe, nicht erneut hochgeladen. Wie das allerdings mit skalierten Bildern aussieht, kann ich zur Zeit nicht sagen, da kann es aber durchaus auch Probleme bei der Erkennung geben. Grundsätzlich ist das allerdings kein Problem von MobileFrontend. MF ist eigentlich ein reines Frontend und stellt i.d.R. keine eigenen Funktionen, wie bspw. Filter oder Ähnliches, bereit oder entwickelt diese. Auch die Dublettenerkennung wird von der Hochladenfunktion durchgeführt, die man vom Desktopupload kennt. Wird beim Desktopupload also keine Dublette erkannt, dann geht es in MF auch nicht. Daher sehe ich hier eher als Ansatzpunkt das Core-Feature zu verbessern. Dann wird das auch bei mobilen Uploads so umgesetzt. Ein generelles Problem in Bezug auf mobile Uploads (man möge sich, falls ich da falsch liege, berichtigen) nicht. --Florianschmidtwelzow (talk) 10:21, 22 July 2014 (UTC)
Dass die Duplikat-Erkennung eine Core-Funktionalität ist, war mir klar. Habe noch einmal genauer hingeschaut: die gelöschte UPC-Datei ist tatsächlich 4297 bytes grösser. Das liess sich von Auge nicht erkennen. Da die Duplikate-Erkennung auf dem SHA1-Hash basiert, kann sie natürlich solche Fälle nicht erkennen, wie auch nicht unterschiedlich skalierte Bilder. Da gibt es aber schon Algorithmen, die das können. Der von Google ist gar nicht schlecht. Leider sind die alle wahrscheinlich zu rechenintensiv für MediaWiki...
Wie wär's mit folgendem: Die Core-Hochladefunktion macht für jeden Mobile/Web upload der als "own work" markiert ist (das scheinen alle zu sein) eine Google-Bildsuche und verweigert den Upload, wenn da mehr als ein Treffer gefunden wird. Gibt zwar ein paar wenige "false positives", aber die können ja normal via Desktop-Upload hochgeladen werden. :-) Lupo 10:49, 22 July 2014 (UTC)
Die Idee mit einer Google Bilder suche nach ähnlichen Bildern klingt erst mal ganz gut, allerdings ist mir nicht bekannt, dass Google für dieses Feature eine API bereitstellt, noch weiß ich (das ist nun nur auf mich bezogen) wie man diese verwendet (und ob wir die in MediaWiki einbauen können/wollen), das ließe ich aber erlernen. Dann kommt noch die "Problematik" hinzu: Inwieweit macht uns das abhängig von Google, wie werden Bilder, die so zu Google hochgeladen werden, weiter verwendet (in puncto: Copyright/Copyleft). Inwieweit andere Vergleichsmethoden für Mediendateien verwendbar ist, muss man von Lösung zu Lösung neu diskutieren und entscheiden. Aber prinzipiell klingt es auf den ersten Blick als eine (wenn nicht gar die einzig technische) Lösung des Problems. — Preceding unsigned comment added by Florianschmidtwelzow (talk • contribs) 15:42, 22 July 2014‎ (UTC)
Zur technischen Seite davon: Ein API dafür ist mir auch nicht bekannt; ich verwende manuell jeweils "https://www.google.com/searchbyimage?image_url=$1", wobei $1 = encodeURIComponent(url_des_bildes_auf_commons). Das gibt HTML zurück. MediaWiki müsste halt temporär die Datei unter einer URL verfügbar machen. Aber WMF hat meines Wissens gute Verbindungen zu Google: einfach fragen! Würde mich nicht wundern, wenn Google dann sogar ein API mit ordentlichem JSON-Resultat dafür baut, wenn's das nicht schon gibt. Ansonsten im HTML-Resultat nach "/imgres?" suchen: falls vorhanden, Treffer, falls nicht: kein Treffer. Lupo 16:21, 22 July 2014 (UTC)
"Ansonsten im HTML-Resultat nach "/imgres?" suchen": Prinzipiell möglich, allerdings birgt das Gefahren für Probleme. Wenn die Ergebnisseite von Google über Nacht Quellcodemäßig anders aufgebaut wird funktioniert diese Lösung auf ein mal nicht mehr. Eine API wäre mir da lieber :) Bin mal gespannt, was vom Mobile team kommt. (Signatur nicht vergessen :P) --Florianschmidtwelzow (talk) 16:30, 22 July 2014 (UTC)
Mir auch :-) HTML-scraping ist immer fehleranfällig. Als proof-of-concept oder stop-gap wäre das allerdings schon eine Möglichkeit... Lupo 17:20, 22 July 2014 (UTC)
"Als proof-of-concept oder stop-gap wäre das allerdings schon eine Möglichkeit": Durchaus, aber da muss ich zugeben, hoffe ich, dass wir das anders gelöst bekommen :P So kann ich mir gut vorstellen, dass bspw. eine Begrenzung auf einen Editcount auch bei den Duplikaten eine erhebliche Verbesserung bringen könnte. --Florianschmidtwelzow (talk) 18:35, 22 July 2014 (UTC)

Verlorene Infos[edit]

Übrigens kriegen wir seit ein paar Tagen sogar Mobile/Web upload ohne jegliche Information, wie z.B. File:Bagunkaka.jpg (ist sowieso Schrott, aber extra nur als "no license" markiert, damit es noch ein wenig hier bleibt und die Devs vielleicht etwas damit anfangen können). Drei weitere sind in bugzilla:68321 erwähnt. Lupo 14:04, 21 July 2014 (UTC)

"autoconfirmed" only[edit]

Es hat sich gezeigt, dass die "Verbesserung" vom 10. Juli (nur Benutzer, die auf dem lokalen Wiki "autoconfirmed" sind, können Mobile/Web upload benutzen), noch fehlerhaft war, und deshalb immer noch non-autoconfirmed Benutzer das Feature benutzen konnten. Siehe bugzilla:68414. Hoffentlich verbessert sich die Lage weiter, wenn diese zusätzliche Korrektur aufgeschaltet wird. Lupo 10:14, 23 July 2014 (UTC)

Was mir gerade noch aufgefallen ist, ist die Tatsache, dass Benutzer auch ohne autoconfirmed-Status direkt zur Seite Special:Uploads navigieren können und dort den Uploadbutton nutzen können. Der Patch, der dieses Problem behebt, würde erst mit MW1.24wmf14 deployed werden (gestern geschehen), da der Patch erst am 15. Juli gemerged wurde (https://gerrit.wikimedia.org/r/#/c/143822). Das könnte, je nach Nutzungsverhalten, zusätzlich die Auswertung der Daten erschweren, bzw. verfälschen. --Florianschmidtwelzow (talk) 12:06, 23 July 2014 (UTC)

Weiter ist inzwischen auch zu den MediaWiki-Entwicklern durchgedrungen, dass ihre limn-Statistiken über gelöschte Uploads ganz einfach falsch sind. Entweder nicht aktuell oder inkomplett oder einfach total daneben. Schaut man in den Upload-Logs direkt nach, findet man weitaus mehr Löschungen von Mobile/Web-Uploads als auf dieser Statistik rapportiert. Das hat die Kommunikation zusätzlich erschwert, da Leute aus dem WMF-Team sich diese Statistik angeschaut haben und dann der Meinung waren, es gebe doch gar kein Problem... Na ja, diese Fehlinterpretation sollte nun ausgeräumt sein. Lupo 10:14, 23 July 2014 (UTC)

Ich frag mich wofür einige leute bei der WMF überhaupt bezahlt werden... *kopfschüttel* --Steinsplitter (talk) 21:43, 23 July 2014 (UTC)
Wow. Beim lesen von bugzilla:62598 und bugzilla:68375 kommt einem ja der Kaffee wieder hoch. Un-glaublich. Tausend Dank an Lupo fürs engelsgeduldige Nachzählen!! Und danke an user:Legoktm für den niederschmetternden Löschquotenvergleich, "numbers for after july 10: 2.8% deletion rate overall, 51% deletion rate on mobile, 2.6% deletion rate on desktop (calculated by overall-mobile)" - Mobile-web-upload Problem, welches Problem?^^ OMG. Im Rückblick wäre Steinsplitters Radikalvorschlag RfC + Mobile-web-upload-block vielleicht zielführender gewesen, dann hätte sich WMF wohl mehr und früher dafür interessiert... eine ziemlich bittere Lehre. Commons kann sich nur jeden Tag beglückwünschen, dass der MP4-Video-Upload RfC abgelehnt wurde, das will ich mir gar nicht vorstellen, was hier sonst los wäre... --Atlasowa (talk) 10:50, 24 July 2014 (UTC)
Nein. Zielführend in solchen Fällen ist alleine Engelsgeduld und AGF. Die Entwickler dieses Features sind ja nicht darauf aus, uns unbrauchbare Software aufzuzwingen. Es ist keine "Wir-gegen-sie"-Situation; letztlich liegt allen Beteiligten die Verbesserung von Wikipedia am Herzen. Die Entwickler glaubten, ein tolles und gutes Feature geliefert zu haben, sonst wäre das gar nicht erst freigeschaltet worden. Da muss man halt erst einmal Überzeugungsarbeit leisten, um aufzuzeigen, dass das Feature vielleicht vom technischen Standpunkt ganz ordentlich ist, aber leider nicht die Anforderungen für einen generellen produktiven Einsatz erfüllt. Man muss genau aufzeigen, was genau denn schlecht ist, und wo das Problem liegt. Früher war das noch etwas einfacher, da die meisten Entwickler zugleich erfahrene Wikipedia-Autoren waren. Heute hat WMF soweit expandiert und sich professionalisiert, dass einige (viele?) Entwickler selbst nicht sehr Wikipedia-erfahren sind. Damit sind (leider) auch umfangreichere Erklärungen nötig, und es gibt mehr Möglichkeiten für Missverständnisse.
Sicher lief da nicht alles ganz rund in diesen Diskussionen, aber letztendlich bin ich für's Erste recht zufrieden. Wir haben die Message 'rübergebracht, und ich habe den Eindruck, sie wurde jetzt auch verstanden. Ich bin jedenfalls auf die weitere Entwicklung gespannt. Lupo 11:54, 24 July 2014 (UTC)
Danke Lupo, für deine ruhige Antwort. :-) So richtig geholfen hat es meinem Blutdruck bisher noch nicht, ich versuche es jetzt mal mit Entspannungsübungen ;-) --Atlasowa (talk) 10:23, 26 July 2014 (UTC)

Einige haben es sicher mitverfolgt: Der Patch zur Beschränkung des Uploads auf einen bestimmten Editcount (https://gerrit.wikimedia.org/r/#/c/143751/9) wurde gestern gemerged. Aktuell würde dieser aber frühestens am 12. August auf Commons deployed werden, daher habe ich im Bug nachgefragt, ob es sinnvoll ist, diesen auf MW1.24wmf15 zu "backporten", sodass er am 29. Juli auf Commons deployed wird. Denn nachdem der Patch produktiv ist, muss noch die Konfiguration angepasst werden, damit auf Commons ein Editcount (bspw. 75) greift. Das nur zur Info und was noch getan werden muss :) --Florianschmidtwelzow (talk) 16:58, 26 July 2014 (UTC)

Weitere Schritte[edit]

  • Danach soll ein fixer minimaler Editcount eingebaut werden. Benutzer mit weniger Edits, ob autoconfirmed oder nicht, können dann nicht mehr via Mobile/Web hochladen. Dies soll in wenigen Tagen geschehen. (Siehe bugzilla:68375#c7 und bugzilla:62598#c128.)
  • Falls man danach nach einer Woche zum Schluss kommt, dass das immer noch nicht geholfen hat, soll das Feature vorerst abgeschaltet werden, bis man eine bessere Idee hat, wie man die "bad uploads" vermeiden bzw. eindämmen kann. (Siehe ebenfalls bugzilla:68375#c7.)

Es tut sich also etwas. Lupo 21:34, 23 July 2014 (UTC)

Statistiken[edit]

Die Statistiken über die Anzahl Löschungen von Mobile/Web Uploads sind falsch (oder ziemlich out of date). Siehe bugzilla:62598#c95 und folgende. Auch die Statistik über die Anzahl erfolgreicher Mobile/Web Uploads scheint suspekt. Lupo 17:55, 28 July 2014 (UTC)

gleiche Bilder[edit]

Hallo zusammen,

es gibt bei gleiche Bilder bei Wiki und bei Commons

Bitte bei Wiki löschen, wenn alle übertragen sind--Vielen Dank und Grüße Woelle ffm (talk) 11:13, 1 August 2014 (UTC)

✓ Done Das ist eigentlich die Aufgabe des Wikis (da hier eigentlich schon genug Ressourcen gebunden sind bzw. nicht verfügbar sind, ich habe die Dateien mal verlinkt). Siehe dieser brandaktuellen Seite de:Hilfe:Dateien nach Commons verschieben (hust*) Bzw. scheinst du den MediaViewer zu verwenden oder einem anderen Irrtum zu unterliegen, da diese teilweise nie auf DE lagen oder schon lange gelöscht sind (jedenfalls alle vor deinem Post). Oder ich irre mich, allerdings ist deine Ausführung auch nicht so genau (vor allem grammatikalisch).
Hallo, ich habe den Artikel angeschaut und die Bilder geöffnet. Hierbei werden die Bilder von Wiki de geöffnet. ich habe jetzt im Artikel Datei durch File geändert. Trotzdem wird das weiterhin von Wiki de geöffnet--Vielen Dank und Grüße Woelle ffm (talk) 14:28, 2 August 2014 (UTC)
Hast du vielleicht Überspringen der lokalen Dateibeschreibungsseite, um sofort nach Commons zu kommen. in deinen Gadget-Einstellung deaktiviert?    FDMS  4    15:20, 2 August 2014 (UTC)
wo finde ich diese Einstellung⁇--Vielen Dank und Grüße Woelle ffm (talk) 15:49, 2 August 2014 (UTC)
Unter Einstellung/Helferlein (irgendwo unten steht was von Commons, beim aktiven MediaViewer natürlich außer Funktion) Im Artikel die Dateilinks zu ändern war jetzt natürlich nicht Sinn der Sache.hm Da, wie hier zu sehen, bereits alle auf Commons liegen (die Namensgebung Englisch/Deutsch für den Namensraum ist auf DE dabei unerheblich, es sind einfach Synonyme). Respektive ist eine unterscheidbare Einbindung gar nicht möglich, vgl. de:Kategorie:Datei:ShadowsCommons. User: Perhelion (Commons: = crap?) 18:44, 2 August 2014 (UTC)


@ User: Perhelion, Woelle ffm: Siehe de:Wikipedia:Administratoren/Anfragen#MediaWiki:Gadget-Direct-link-to-Commons.js bitte für unangemeldete Benutzer deaktivieren, wurde für alle deaktiviert (jetzt wird auf lokale deWP-Dateiseiten geleitet). Commons ist jetzt praktisch abgeklemmt ^^

  • MediaWiki:Gadget-Direct-link-to-Commons.js: "Da das Gadget als Standard für alle Benutzer aktiviert ist, sollte eigentlich kein Benutzer dieses Gadget laut Datenbank aktiviert haben (so wie das auch für gadget-old-movepage der Fall ist), der eine Benutzer hat das Gadget wohl ganz am Anfang, wie es noch kein Standard war, aktiviert und seitdem nichts mehr an seinen Einstellungen verändert." [3]
  • 2,58% aller Benutzer, die zumindest eine Bearbeitung in den letzten 30 Tagen vorgenommen haben, haben den Medienbetrachter abgeschaltet (522 Benutzer)
  • Die Durchklickrate vom WP-Medienbetrachter zur Dateiseite bei commons ist minimal,
    • MMV deWP stat: auf (täglich) 1,25 Millionen thumbnail-klicks kommen ca. 1.000 klicks zur commons file description page, also Promillebereich.
    • MMV global stat: auf (täglich) 10 Millionen thumbnail-klicks kommen ca. 12.000 klicks zur commons file description page, also ebenfalls Promillebereich.
  • Der traffic zu commons ist mit Anschalten des Medienbetrachters abgefallen: [4], [5], usw.

Übel. --Atlasowa (talk) 19:40, 2 August 2014 (UTC)

Hallo Atlasowa, vielen Dank für den Hinweis und Erklärung! Ich hatte es nie umgestellt und bin auf bei Wiki und hier dauern unterwegs. >hier< auch ein Thema.--Vielen Dank und Grüße Woelle ffm (talk) 06:42, 3 August 2014 (UTC)

Ich bin nicht sicher, ob ich die Diskussion verstanden habe. Kann ich Bei Bildaufruf gleich Commons-Beschreibungsseite anzeigen (lokale WP-Seite unterdrücken) aus meiner Vector.js löschen, weil das sowieso nicht mehr geht? Gruß, --Schwäbin (talk) 03:14, 4 August 2014 (UTC)
Jain :P, es funzt nur nicht mit dem MV. Da es das Gadget gibt, kannst du aber deinen Code trotzdem löschen, allerdings müss nun jeder Benutzer das Gadget manuell wieder anschalten. Das alles ohne informiert worden zu sein, empfinde ich ebenfalls nicht als sehr professionell, gelinde gesagt. PS: Deine Scripeinbindungen sehen eh veraltet aus, ich empfehle die Scriptsammlung Fliegelflagel (dort wirst du auch elegant über Neuigkeiten/Änderungen informiert und das alles von nur einer Person die keine Zeit hat </IronieOff>) Die benutze ich sogar hier. User: Perhelion (Commons: = crap?)09:12, 4 August 2014 (UTC)
Danke für die Info. Und ja, sie SIND veraltet :-) --Schwäbin (talk) 19:42, 4 August 2014 (UTC)
Zurzeit funktioniert der Umsprung, trotz Haken bei Wiki nicht--Vielen Dank und Grüße Woelle ffm (talk) 10:14, 10 August 2014 (UTC)
Siehe Antwort dort. User: Perhelion (Commons: = crap?)11:47, 10 August 2014 (UTC)

de:WP:?#Armeefilmsequenz für Katzenartikel[edit]

Mag da jemand helfen? Es geht um lizenzrechtliche und technische Aspekte für den Upload dieses Videos. Ich kenne mich damit wenig aus. --Leyo 19:03, 4 August 2014 (UTC)

Voilà, da ist es. Kann sich nochmal jemand um Kategorisierung und evtl. Bausteine kümmern? Danke! --Atlasowa (talk) 11:37, 5 August 2014 (UTC)
Katzensturz in der Schwerelosigkeit eines Parabelflugs, USAF Aerospace Medical Research Lab.
Danke. Eine Kategorie habe ich noch etwas verfeinert, aber sonst passt es IMO. --Leyo 17:18, 5 August 2014 (UTC)

Das ist aber - außer in Fällen von PD wie hier - ein Lizenzrechtliches Problem, daß Filme nicht automatisch mit der Bildbeschreibungsseite verliinkt werden! --Kersti (talk) 13:54, 5 August 2014 (UTC)

Das habe ich schon lange moniert (z. B. bugzilla:43747). Bei der Einbildung als Thumb gehts ja noch, da kannst du auf Magnify-clip.png klicken. Ansonsten im Video unter "Menü" die Lizenzinfos sehen. --тнояsтеn 13:59, 5 August 2014 (UTC)
Bildunterschrift + rechts statt Magnify-clip.png -> Media Viewer Icon - Commons Gray.svg mit Link
Leyo, тнояsтеn: Danke für die Cat Hilfe ;-)
Ich sehe ebenfalls das Problem von Kersti, danke für den bugzilla-Link (bugzilla:43747 - Link to file description page is undiscoverable or completely missing), das wurde vor über einem Jahr bereits angesprochen: Commons:Forum/Archiv/2013/April#eingebettete Videos - Wie zur Datei-Seite gelangen?
тнояsтеn hatte ein ähnliches Problem angesprochen, weil nämlich bei den thumbnail-Bildern ebenfalls der Direktlink per Lupensymbol Magnify-clip.png entfallen soll/sollte, und ob dann überall das hässliche blaue i Desc-20.png kommen soll:
Siehe auch zur neueren Entwicklung anlässlich MediaViewer + mw:thumbnail style update:
Beim letzten Link steht auch mein Vorschlag, nämlich:
Was mir hier wirklich fehlt, - Medienbetrachter hin, nackte-thumbs her - sind die Direktlinks zu Commons. Weil sonst mein workflow gestört wird (klick, klick, ...) und wegen den Lizenzinfos (diese ganzen Artikel via google news mit "Bild: Wikipedia" deuten eine verbreitete Unkenntnis über Lizenzinfos an....). Also, machen wir jetzt an alle Bilder das da: Desc-20.png mit einem Link zu commons dran? Das geht hübscher und besser, oder? Wenn das Bild von commons ist, dann das icon mit Link: Wikimedia Commons favicon.png oder das: Media Viewer Icon - Commons Gray.svg. Und wenn es eine lokale Datei von de.WP ist, dann ein anderes icon, so dass man auf einen Blick erkennen kann wo es hin geht. Dann könnten wir auch auf den ganzen MediaViewer opt-in/opt-out Quatsch verzichten, und Wikipedianer sehen das gleiche wie Leser auch. Im MediaViewer selbst gibt es bereits das commons-icon Media Viewer Icon - Commons Gray.svg rechts unten, das zur Commons-Dateiseite führt, das wäre also konsistent. Am besten fände ich: rechts unter den Bildern in Wikipedia das commons-icon Media Viewer Icon - Commons Gray.svg, das direkt zur Commons-Dateiseite führt, und bei lokaler Bilddatei mit einem anderen icon (möglichst etwas weniger hässliches als das blaue i Desc-20.png oder das Lupensymbol Magnify-clip.png). Ich glaube auch, dass das visuelle Verbinden von Commons-Symbol und Wikipedia-Bildern den Wiedererkennungswert von Commons bei Lesern (und Bildnachnutzern!) sehr steigern wird. Vorteile:
(a) Dann könnte jeder Wikipedianer, jeder Neuling, jeder Leser direkt zu Commons durchklicken, wenn er will, ohne opt-in/opt-out. (Das ist leicht zu erklären und zu finden, jedenfalls einfacher als Browser-Support für newbies mit Rückfragen à la "Was passiert, wenn Du auf das Bild klickst, landest du in einer schwarzen Diashow, oder öffnet sich ein anderer Tab?")
(b) Man sähe sofort, ob das Bild lokal ist oder von Commons. Auch in anderssprachigen WP.
(c) Und mehr Leute/Leser/Nachnutzer würden verstehen, wo die Bilder herkommen und was commons.wikimedia ist.
(d) Außerdem könnte man vielleicht auf das icon ein Mouseover legen mit der korrekten Attribution+Hinweis auf Commons.
Und das ganze natürlich so auch bei Videos. --Atlasowa (talk) 10:08, 6 August 2014 (UTC)

Category:X als Abschnitt einbinden[edit]

Hallo zusammen,,

ich wollte die Category:Stolpersteine als Abschnitt bei Cobblestone einbinden. Leider mag das nicht so wie ich möchte.

Gibt es eine intelligente Lösung hierfür?--Vielen Dank und Grüße Woelle ffm (talk) 06:23, 6 August 2014 (UTC)

@Woelle ffm: weiß nicht was genau du vorhast, aber ich hab "redirect" durch {{cat see also}} ersetzt. Holger1959 (talk) 14:30, 6 August 2014 (UTC)
Hallo Holger, genau das ist was ich gesucht habe.--Vielen Dank und Grüße Woelle ffm (talk) 14:50, 6 August 2014 (UTC)

PDF gröser als 100 MB hochladen[edit]

Kann jemand dieses PDF das ein bisschen grösser als 100 MB ist hochladen? thx--Sanandros (talk) 07:22, 6 August 2014 (UTC)

Versuch mal Commons:Hochladen in Blöcken. --тнояsтеn 07:31, 6 August 2014 (UTC)
Also ich habe das alte Formular gewählt. Beim Wizard kommt mit dem Blockupload die folgende fehlermedlung: https://bits.wikimedia.org/commons.wikimedia.org/load.php?debug=false&lang=de&modules=ext.uploadWizard&skin=vector&version=20140806T023438Z&* at line 0: Script error. Benutze FF 31.0.--Sanandros (talk) 12:51, 6 August 2014 (UTC)
Also der Fehler ist relativ nichtssagend, da die Scripte hier auf eine Zeile komprimiert sind (was natürlich bei Beta-Scripts ein wenig doof ist). Ich habe die Datei mal hochgeladen File:2013-watchlist-guidance.pdf, allerdings musst du den Rest ausfüllen. Ich habe auch keine Ahnung ob die Lizenz richtig ist. PS: Ich hatte mit Chrome keine Probs. Grüße User: Perhelion (Commons: = crap?)07:30, 7 August 2014 (UTC)
Was mich ein klein wenig verunsichert ist dieser Text: FOR OFFICIAL USE ONLY !? User: Perhelion (Commons: = crap?)09:07, 7 August 2014 (UTC)
Ja da steht auch SECRET und NOFORN. Das heisst das Ding sollte eigentlich geheim bleiben und kein Bürger der nicht Amerikanisch ist darf das Dokument ansehen. Jedoch sind dies keine Urheberrechtlichen Einschränken. Noch mals vielen Dank.--Sanandros (talk) 16:18, 7 August 2014 (UTC)

Fanta doppelt?[edit]

Für Fanta gibt es eine Commons Seite Namens "Fanta" und eine "Category:Fanta". Erstere wurde beim Bildupload in der Katergorieliste gefunden, letztere nicht. Erstere dafür ignoriert, zweitere nicht. Da ist glaub ich was im Argen, was mein Verständnis übersteigt??? Dirk1981 (talk) 11:20, 6 August 2014 (UTC)

Wie auf anderen Wikis gibt's hier Seiten (z.b. Fanta) in unserem Haupt-Namensraum. Diese werden manuell erstellt; enthalten hier meist eine Auswahl an Bildern, und sind evtl. hübsch formatiert. Daneben gibt's, ebenfalls wie auf anderen Wikis, Kategorien. Diese zeigen eine automatisch erstellte Ansicht aller in der Kategorie eingeordneten Seiten, Kategorien, und Dateien. In der Kategorieliste werden Kategorien ausgewählt; dabei wird aber das Präfix "Category:" nicht angezeigt, da es ja bei allen Einträgen identisch wäre und es auch überflüssig ist, da der Benutzer in einer Kategorienliste natürlich Kategorien und nicht Seiten angezeigt bekommt. Genauso wie in der Kategorienzeile z.B. bei Paul Kane (eine Seite) nicht steht "Categories: Category:1810 births Category:1871 deaths Category:Paul Kane Category:Native Americans in art" sondern einfach "Categories: 1810 births 1871 deaths Paul Kane Native Americans in art". Lupo 11:50, 6 August 2014 (UTC)

hochgeladenes Foto in konkreten Wikipedia-Artikel einbinden[edit]

Wie schaffe ich es, ein erfolgreich hochgeladenes Foto bei Wikimedia nun dem gewünschten Artikel bei Wikipedia zuzuordnen. Ich krieg's irgendwie nicht hin. Wenn ich die Funktion "Einbinden in ein Wiki" wähle, passiert nichts - lediglich ein Dialogfenster öffnet sich mit der Wiedergabe der Bilddatei, ohne weitere Möglichkeiten. Es muß doch einfach und schnell schaffbar sein, einem Wortartikel das Foto hinzuzufügen, das bereits hochgeladen wurde. Wer weiß mehr? Herzlichen Dank. — Preceding unsigned comment added by Prädikat (talk • contribs) 13:31, 6. Aug. 2014‎ (UTC)

Den Wikipediaartikel öffnen, [[Datei:Musiker und Komponist Walter Wachsmuth, Braunschweig 1910.jpg|mini|Deine Beschreibung für das Bild]] ganz oben einfügen (bzw. in eine Positiom Deiner Wahl), und fertig. Das Bild erscheint automatisch rechts oben. Grüße --Trzęsacz (talk) 11:52, 6 August 2014 (UTC)
Die Datei ist allerdings ein Reprofoto. Von wo stammt die ursprüngliche Aufnahme? Wohl kaum vom 2000 gegründeten Fotostudio Flentge. Wann wurde die ursprüngliche Aufnahme gemacht, von wem, und wo und wie veröffentlicht? Lupo 11:56, 6 August 2014 (UTC)

Andere Fotoprojekte[edit]

Hallo wertes Fachpublikum!

Neben dem Commons-Fotostock gibt es noch weitere wie Gettys und Fotolia. Hat jemand der Commons-Photographen auch Erfahrung mit der Zusammenarbeit mit diesen beiden Projekten (insbes. eigene Medienbeiträge)? Herzliche Grüße, Florian Weber

[edit]

Wenn das geht, dann bitte irgendwie den Gewinner des Wettbewerbs "WikiLovesEarth" auf seine fehlende Mail-Adresse hinweisen.

Hallo Satohan, wir können dich nicht erreichen!

Vielleicht kennt ja ein andere den Uploader und kann ihn informieren. Vielleicht hat ja auch jemand hier eine bessere Idee. Gruss --Nightflyer (talk) 23:15, 6 August 2014 (UTC)

Ein Einmaleditor, das erinnert mich an den Lottogewinner der nicht zur Einlösung kam... User: Perhelion (Commons: = crap?)05:46, 7 August 2014 (UTC)
Hallo, muss ich nicht, um mich bei der Wiki Familie anzumelden eine Email angaben und dann den Link bestätigen?? darüber vielleicht?--Vielen Dank und Grüße Woelle ffm (talk) 05:59, 8 August 2014 (UTC)
Nein, die Angabe einer E-Mail-Adresse ist freiwillig. --тнояsтеn 06:33, 8 August 2014 (UTC)
Also ich habe mir die Artikel Naturschutzgebiet Heuckenlock, Liste der Naturschutzgebiete in Hamburg, Liste der Hamburger Geotope angeschaut und der Indeedous hat das Bild eingefügt. Ist dieser Satohan eine Sockenpuppe von ? --Vielen Dank und Grüße Woelle ffm (talk) 06:09, 8 August 2014 (UTC)
Nein, dieser Indeedous war einer der Juroren, die das Bild auf Platz 1 gewählt haben und hat es deshalb eingefügt, weil wir an einer angemessenen Verwendung unserer Siegerbilder interessiert waren. Eine Sockenpuppe wäre in diesem Fall schon arg unsportlich. Mit Bannern kenne ich mich leider nicht so gut aus. --Indeedous (talk) 08:18, 8 August 2014 (UTC)
Sollte auch keine Unterstellung sein! Es war nur auffällig bei dem gleichen Datum--Vielen Dank und Grüße Woelle ffm (talk) 08:28, 8 August 2014 (UTC)

Kategorien: architecture vs. buildings[edit]

Hallo zusammen, ich bin gerade dabei etwas aufzuräumen, doch bei den Kategorien architecture und buildings stoße ich an meine Grenzen. Scheinbar werden sie wahllos und teilweise synonym benutzt (bspw. Religious architecture / Religious buildings). Der Kategoriebaum hilft leider auch nicht wirklich weiter. Welche Struktur wird für was angewendet? lg --Sjokolade (talk) 10:09, 7 August 2014 (UTC)

Prinzipiell habe ich da keine Ahnung ;) Aber hier steht was dazu: Commons:CommonsProject Architecture#Classification help. --тнояsтеn 11:11, 7 August 2014 (UTC)
danke, ich hab glaube ich die Antwort gefunden: neben Gebäuden gibts ja noch Modelle, Zeichnungen, Skulpturen und Strukturen - fällt ja irgendwie unter Architektur... lg --Sjokolade (talk) 12:20, 7 August 2014 (UTC)

Dateien ohne Vorlagen[edit]

Hallo zusammen, gibt es irgendwo ein Tool, das mir alle Dateien auf Commons ausgibt, die nur Plaintext-Beschreibungen enthalten (bei denen also Vorlagen wie Information o. Artwork usw. fehlen)? Gibt es einen Bot o. ein Skript das die Konvertierung von Plaintext auf Vorlage unterstützt? Gruß, --Arnd (talk) 11:08, 7 August 2014 (UTC)

Vielleicht http://misterwiki.host22.com/tools/mynoinfo.php oder http://misterwiki.host22.com/tools/add_information.php ? --Dschwen (talk) 20:06, 15 August 2014 (UTC)

Eigenes Werk?[edit]

Ist Kennzeichnung als "Eigenes Werk" für File:Bahnkarte_Isartalbahn.jpg richtig? Oder wäre abgeleitetes Werk korrekt? Ist das Neueinstellen nur leicht bearbeiteter historischer Karten unter neuer CC-Lizenz statt Gemeinfrei korrekt? Der Bearbeiter scheint das zu glauben und hat so schon viele Karten als "Eigenes Werk" auf Basis anderer gemeinfreier Werke eingestellt. Scheint mir so problematisch. Siehe [7] --> Eigenes_Werk? --RöntgenTechniker (talk) 17:27, 7 August 2014 (UTC)

Der Vollständigkeit halber auch ein Link zu de:Wikipedia Diskussion:Kartenwerkstatt#"Eigenes Werk". --тнояsтеn 19:55, 7 August 2014 (UTC)
Mangels Reaktion hier unter Commons:Village_pump/Copyright#Own_Work.3F zur Diskussion gestellt.--RöntgenTechniker (talk) 13:00, 14 August 2014 (UTC)

Artnamenseiten (Gallery)[edit]

Für Tierarten (ich nehme an auch Pflanzenarten) sind unter dem wissenschaftlichen Namen Seiten in Wikimedia angelegt, die neben den Artnamen in verschiedensten Sprachen auch eine Bildergalerie enthalten.

Bisher ging ich wohl irrtümlich davon aus, dass das ne Art Suchseite für Bilder der gleichen Art ist, weil die Gallerien bisher immer recht gut gefüllt waren...

Am Beispiel Sylvia nisoria wurde ich dagegen eines besseren belehrt: da ist nur ein Bild eingetragen (obwohl die Suche https://commons.wikimedia.org/w/index.php?title=Special%3ASearch&profile=default&search=Sylvia+nisoria&fulltext=Search mindestens vier Bilder ergibt) - einen Tippfehler konnte ich nicht erkennen...

Meine Fragen:

  • was unterscheidet die Kategorieseiten (z. B. Category:Sylvia_nisoria) von den Artnamenseiten (z. B. Sylvia nisoria)?
  • gibt es bots, die die Galerien von den Artnamenseiten füttern oder muss jedes Bild von Hand eingetragen werden?
  • wird da nicht redundante Arbeit betrieben? wäre nicht zu überlegen, die Artnamenseite grunzipiell auf die IMHO automatisch besser gepflegte Kategorieseite weiterzuleiten?
  • anderes Beispiel für fast (aber nur fast) gleiche Seiten: Category:Picus_viridis und Picus viridis

noch etwas zu den Beschreibungen auf den Einzelseiten: Gibt es da eine Konvention zur Grundstruktur? Grundsätzlich halte/hielte ich einen Aufbau mit wiss. Namen in der ersten Zeile (kursiv und verlinkt mit o. g. Artnamenseite) und dann je Sprache eine Zeile mit dem Artnamen in der jeweiligen Sprache, verlinkt mit dem entsprechenden Wikipedia-Artikel und ggf. weitere Details wie Fundort etc. Bei Gelegenheit (z. B. weil ich die deutsche Beschreibung ergänzt habe) habe ich dies bei dem ein oder anderen Bild bereits angefangen umzusetzen. --Kai.pedia (talk) 15:30, 12 August 2014 (UTC)

Das ist ein ungelöstes Problem hier, deshalb wurde auch schon mehrmals diskutiert ob Gal(l)erien nicht abgeschafft werden sollten (bzw. kleine evtl. zu löschen sind).
  1. Bei gleichen Namen sollte sie sich natürlich nicht unterscheiden
  2. meines Wissen nach alles per Hand
  3. IMHO ja
Ich bin auch kein sonderlicher Freund von Gallerien, sie können aber doch ab und zu sehr nützlich sein, z.B bei vollgemüllten Kats, unsortierten, größeren... Damals war auch das Hautpthema kleine Gallerien zu löschen, da sie eher Informationsabweisend sind, vor allem da die Suchfunktion hier automatisch immer auf die Gallerie springt.
(OT PS: Du hast immer noch nicht deine common.js hier eingeweiht :P) User: Perhelion (Commons: = crap?)21:57, 12 August 2014 (UTC)
Hallo, ich sehe das anders mit "Gleichheit" zwischen Category und Gallery. - In die Category gehört jede Datei, die zu dem entsprechenden Motiv gehört, eingetragen wird sie dort automatisch durch den Eintrag "Category:something" in der Dateibeschreibung, gilt natürlich auch für weniger "gute" Fotos (unscharf, klein, zu dunkel). Auch gibt es in den Categorien bei den Dateien selbst nur den Dateinamen als "Beschreibung", manchmal eben nur DSC0815.jpg. - Bei den Gallerien handelt es sich um "normale", editierte Seiten, bei denen nur sinnvolle (!) Dateien von Hand eingetragen werden "File:something.ext|Hinweis bla bla" und sinnvollerweise auch mit entsprechenden Hinweisen zur Datei/Motiv. Hier sollten, sofern vorhanden, nur die besseren Dateien landen, groß, scharf und gut belichtet, ferner keine unnützen Doppelungen von ähnlichen Dateien, damit die Gallery übersichtlich bleibt. Dabei sollten bei den Gallerien auch Strukturen eingetragen sein, Bei Pflanzen z.B. Ganze Pflanze, Knospe, Blüte, Frucht, Samen, Verbreitungsgebiert (Karte) Habitat usw. Ähnlich für Tiere, Männlich, Weiblich, Jungsters, ggf. Eier, usw. Das ganze kann noch mit entsprechden Hinweisen gewürzt werden. Dein Beispiel von Sylvia nisoria ist eher mager, gibt aber auch nicht viele Dateien. Bei den Picus viridis ist die sinnvolle Gallery-Struktur schon ganz gut zu erkennen. Ähnliches gilt natürlich auch für alle anderen Categoreien / Gallerien (Brücken, Gebäude, Personen, Sport ....). Just my 5 cents NobbiP 22:47, 12 August 2014 (UTC)

Bilder finden, die in mehreren bestimmten Kategorien enthalten sind[edit]

Hallo zusammen. Wie kann ich Bilder finden, die in mehreren bestimmten Kategorien enthalten sind? Konkret möchte ich gern die Bilder haben, die in der Kategorie

enthalten sind.

Zusatzaufgabe: Wie kriege ich alle Bilder angezeigt, die in der Kategorie

enthalten sind.

Danke! --Derbrauni (talk) 14:57, 13 August 2014 (UTC)

Die Lösung heißt Catscan: Anfrage 1, Anfrage 2. — ireas (talk) 15:08, 13 August 2014 (UTC)
Perfekt, danke! --Derbrauni (talk) 16:08, 13 August 2014 (UTC)
Oder Help:FastCCI/de. --Dschwen (talk) 16:13, 13 August 2014 (UTC)

Wieso gibt es keinen lizenzkonformen Einbettungscode?[edit]

http://archiv.twoday.net/stories/948993803/ Habe ich schon gefühlte hundertmal gefragt. Ich kann an dem Blog nichts drehen, so dass der Link zur Lizenz korrekt erscheint, während die Einbettungscodes des Flickr-Bookmarklets und von Geohipp einwandfrei funktionieren. --Historiograf (talk) 20:26, 13 August 2014 (UTC)

Ein Bug report auf Bugzilla wuerde bestimmt mehr erreichen als ein Blogpost (oder auch gefuehlte 100 blog posts). LIzenzkonforme Einbettungscodes gehen der Foundation nicht am Hinetrn vorbei. Das Multimedia team arbeitet mit dem Legal team zusammen. Wenn der Link auf die Lizenz nicht auftaucht ist das ganz einfach ein bug, und wenn es Spezialfaelle wie das de Bild, dass nicht auf commons darf gibt, dann muss das den Leuten jemand sagen, sonst koennen die das auch nicht reparieren. --Dschwen (talk) 21:25, 13 August 2014 (UTC)
Lupo 22:07, 13 August 2014 (UTC)
bugzilla:69497 wurde nach weiterer Analyse meinerseits as Duplikat von bugzilla:57458 geschlossen. Letzterer Bug ist seit November 2013 bekannt und immer noch nicht geflickt. Lupo 14:00, 14 August 2014 (UTC)
@Historiograf, Dschwen, Lupo: hab grade eine Wikidatadiskussion studiert, die hiermit nicht direkt was zutun hat, aber dort fand ich (Beitrag von Bidgee am Anfang) https://bugzilla.wikimedia.org/show_bug.cgi?id=69656 "Lack of attribution in mobile version of MultimediaViewer".
Angeblich gucken ja große Teil der Menschheit Internet nur noch auf Smartphones. Also wenn das so wie in diesem Screenshot bleibt (vergleich Verbesserungsvorschlag, beide Bilder aus Comment 8), dann versteh ich nicht mehr, wofür hier Urheberangaben überhaupt noch nötig sein sollen… Ich glaub mit so einer Standardbilderansicht kann man viele gute Fotografen hier erfolgreich abschrecken! Das ist ja selbst im überarbeiteten Flickr besser gelöst. Vielleicht könnt ihr euch das angucken und auch drum kümmern? Holger1959 (talk) 14:32, 18 August 2014 (UTC)

Kategoriename deutsch oder englisch?[edit]

Tut mir leid für meine geringfügige Ahnungslosigkeit. FAQ lesen half mir irgendwie auch nicht.

Ich kam von einem WP-Artikel [8] hierher und dachte es wäre klug für zwei Bilder eine Kategorie zu machen (weil es ein Baudenkmal ist, um es dann in dieser Liste mit weiteren Bildern aus den Commons verlinken zu können).
Irgendwie war ich der Überzeugung, dass die Kategorie englisch sein sollte und hab das ergo auch so benannt -> Category:Railway bridge Höllental. Hab danach natürlich festgestellt, dass in allen 3 Oberkategorien (die ja in englisch sind) die jeweils letzte Unterkategorie in deutsch ist (z.B. in Category:Cultural heritage monuments in Lichtenberg (Upper Franconia) oder Category:Stone arch railway bridges in Bavaria ).

Aus Commons:Rename a category/de (eine Kategorie umbenennen) (Tut mir leid, hier in WM weiß ich nicht mal wie die Extraseiten verlinkt werden. Bin sonst nur in WP unterwegs.) werde ich jetzt auch nicht schlau was richtig / vernünftig ist.
Sollte ich Category:Railway bridge Höllental also in Category:Eisenbahnbrücke Höllental umbenennen? Oder sogar in Category:Eisenbahnbrücke Höllental (Ofr.) (alldieweil es mehr als ein Höllental in der Welt gibt und es das in Oberfranken ist).
Schönen Dank schon mal. Blart (talk) 19:38, 16 August 2014 (UTC)

Englisch ist bevorzugt aber vorallem Franzosen kategorisieren auch einfach in ihrer eigenen Sprache. Abkürzungen sollten hingegen vermieden werden.--Sanandros (talk) 11:37, 17 August 2014 (UTC)
Commons:Kategorien sagt lediglich: "Die Namen von Kategorien sollten in der Regel englisch sein." (Unterstreichung von mir). Commons:Categories ist etwas ausführlicher: " Proper nouns which have not an established English variant are not translated ad hoc and use the original form." Wenn ich mir z. B. Category:Bridges over the Wupper oder andere Eisenbahnbrücken-Kategorien ansehe, wird hier wohl ziemlich einheitlich immer der deutsche Name verwendet. Bei deiner Kategorie könnte man also auch den deutschen Namen verwenden (und diesen als Eigennamen ansehen). Ist aber ein Grenzfall im Gegensatz zu den meisten Kulturdenkmälern, die einen Eigennamen haben, der dann nicht übersetzt wird. --тнояsтеn 06:37, 18 August 2014 (UTC)
Also kann ich die Kategorie offiziell nach dt. umbennen und werde dann die paar auf die Kategorie linkenden Seiten der WP von Hand ändern wenn ich das richtig sehe. Wenn kein Einspruch kommt mach ich das mal in ein, zwei Tagen. Danke schon mal. Blart (talk) 08:40, 18 August 2014 (UTC)
Besonders im Anbetracht der Tatsache dass ein Medium der Kategorie Höllentalbrücke heißt und es keine offizielle Baudenkmalliste für Bayern mit Namen gibt Eisenbahnbrücke Höllental wohl kaum ein Eigenname … Viele Kategorien (besonders im Eisenbahnbereich) des deutschsprachigen Raumes sind nicht aus Konsens heraus deutsch, sondern weil sich zum Erstellungszeitpunkt jeweils ein oder mehrere aktive Benutzer für solche Namen entschieden haben und sich neuere Benutzer nachvollziehbarerweise diesem scheinbaren Schema angeschlossen haben, was aber nicht durch Policy gedeckt ist. Bitte nicht verschieben.    FDMS  4    11:20, 18 August 2014 (UTC)
Aha. Danke. Na gut, dann habe ich es wohl zufällig ursprünglich richtig benannt als nicht-Eigenname und dementsprechend in Englisch. Werde es nicht umbenennen. Dann bliebe die Frage mit "Nachbarkategorien", also z.B. Bahnhof und Rathaus in Category:Cultural heritage monuments in Lichtenberg (Upper Franconia): sollten die irgendwann auf Englisch umbenannt werden? Blart (talk) 12:54, 18 August 2014 (UTC)
Genau, irgendwann :) . Ich würde wenn ich sie sichte (nicht im MediaWiki-Sinne) fehlerhafte Namen von Kategorien nur korrigieren wenn sie entweder mir besonders wichtig, besonders falsch (z. B. falscher Begriffsklärungszusatz: Special:Diff/131943273, Special:Diff/131943300), erst vor kurzem erstellt worden oder absichtlich falsch benannt sind.    FDMS  4    16:37, 18 August 2014 (UTC)
Hab vor deinem Beitrag hier schon gesehen, dass die zwei Kategorien geändert wurden. Schönen Dank. :-) Das "irgendwann" sollte also bei sowas auch mal als "sei mutig" interpretiert werden. (Wie du sagst, wenn mir etwas an einer Kategorie liegt. Also wenn mir etwas über den Weg läuft was ich als meinen Verantwortungsbereich definiere.) Ach ja, das Verschieben erstellt automatisch eine Weiterleitung des alten Namens? Das ist gut, dann kann man zumindest auch keine Links kaputt machen. Na, dann werd ich mal mutig sein. Blart (talk) 17:08, 18 August 2014 (UTC)
Wo es hier gerade um das Thema geht: Sollte man solche Kategorien nicht besser umbenennen, hier konkret in St. Marien (Lemgo)? --Magnus (talk) 13:03, 18 August 2014 (UTC)
Du hast jetzt aber schon oben mitgelesen über Eigennamen. Wenn Du es z. B. mit Category:St. Mark's Basilica (Venice) vergleichst und obigem Text, dann genau nicht. Aber ein einführender Satz in verschiedenen Sprachen kann sinnvollerweise der Kategorieseite (tl LangSwitch) hinzugefügt werden.--Oursana (talk) 21:41, 18 August 2014 (UTC)
Ich habe es gelesen und frage ja deshalb. Ist St. Marien kein Eigenname? Deinem Beispiel kann ich die übrige Befüllung der Oberkategorie entgegenhalten. Ich denke, es kommt doch sehr darauf an, ob ein Gebäude nur regional bzw. für den deutschsprachigen Raum relevant ist oder ob es international rezipiert wurde. Im letzteren Fall mag es eine offizielle Übersetzung ins Englische geben, ich bin aber der Meinung, hausgemachte Übersetzungen sollten vermieden werden. --Magnus (talk) 06:33, 19 August 2014 (UTC)
{{mld}} wäre richtig, siehe Template:I18n templates.    FDMS  4    14:53, 19 August 2014 (UTC)

Da ging was schief[edit]

Ich hatte vorgeschlagen einen Satz zu ändern.

Jetzt steht beim normalen Hochladen ein deutsch/englischer Satz:

Maximale Dateigröße: 100 MB (your chosen file from your computer)

Ich bitte den Fehler zu bereinigen, falls die WMF das noch erlaubt und nicht auch hier "superprotect" angewendet hat. Gruss --Nightflyer (talk) 22:24, 16 August 2014 (UTC)

Sicher, dass du das richtig eingestellt hast? MediaWiki:Upload source file/de sowie die zugehörige Seite im Translatewiki zeigen mir die Übersetzung an. Grüße, —DerHexer (Talk) 23:29, 16 August 2014 (UTC)
Hm. Normalerweise steht bei mir ganz oben: "Deutsch". Gehe ich auf "Datei hochladen", "Es ist ausschließlich meine eigene Arbeit.", verschwindet das Wort "Deutsch". Allerdings ist die Uploadseite weiterhin in deutsch, bis auf den oben genannten Satz. Verlasse ich die Uploadseite, kommt oben ganz kurz die Meldung "Sprache geändert von deownwork (Oder so ähnlich, ist sehr kurz sichtbar)". Ist das irgendwie mein Problem, an meinen Einstellungen habe ich lange nichts verändert? Gruss --Nightflyer (talk) 08:50, 17 August 2014 (UTC)
KA. was sich die Entwickler dabei gedacht haben, den uselang-Parameter für das Upload-Form zu „missbrauchen“. Ich habe den Fehler auch (obwohl ich selber einen Upload-Hack verwende, s. bei mir) Daher ist der Fehler wohl hier: MediaWiki:Upload source file/deownwork User: Perhelion (Commons: = crap?)10:22, 18 August 2014 (UTC)
PS: Dabei habe ich mich schon immer gefragt, was der Unterscheid zwischen den beiden wählbaren Arten Standardformular und einfache Formular man fühlt sich einfach richtig verarscht.:-P User: Perhelion (Commons: = crap?)10:32, 18 August 2014 (UTC)
PPS: Des Weiteren fühlt man sich "verarscht", wenn man den Dateinamen bereits sorgsam ausgefüllt hat und "dann" die Datei zum Upload auswählt!(~_~) Ist das nicht ein BugReport wert!? User: Perhelion (Commons: = crap?)10:37, 18 August 2014 (UTC)
Ich weiß ja nicht, was du siehst, aber bei mir gibt es einen deutlichen Unterschied zwischen Standardformular (getrennte Formularfelder, mit Erklärungen zu jedem Eingabefeld) und dem einfachen Formular (quasi Wiki-Plaintext, gut für copy&paste). --Magnus (talk) 11:23, 18 August 2014 (UTC)
Wie gesagt, ich sehe keinen einzigen Unterschied, bis auf auf den anderen URL-Parameter. Ich denke du meinst einfach das Gadget: MediaWiki:UploadForm.js/Documentation!? Welches ich deaktiviert habe, da es nicht richtig funzt. Falls das der Grund sein sollte, ist die Beschreibung für dieses "Extraformular" ebenfalls "für'n Arsch" Hintern. Schönen Tag User: Perhelion (Commons: = crap?)11:43, 18 August 2014 (UTC)

{{Edit request|technical=1}}

Es gibt augenscheinlich nicht mehr viele Admins hier die wirklich Ahnung von der Materie haben (mir sind jetzt die letze Woche 3 sehr bedeutende aufgefallen die sich zur Inaktivität bekundet haben ) Ich werde diesem Bsp. auch bald folgen und das Spielfeld verlassen... GoodBye.hi
Einen schönen Gruß noch an DerHexer, den ich noch als einfachen kleinen Vandalenjäger aus deWP kannte (wer hätte an so eine Laufbahn gedacht). User: Perhelion (Commons: = crap?)18:07, 19 August 2014 (UTC)
Merkwürdig: Wenn ich Datei hochladen wähle, ist der Text in englisch. Will ich ein vorhandenes Bild neu hochladen, ist der gewünschte deutsche Text vorhanden. Gruss --Nightflyer (talk) 21:09, 19 August 2014 (UTC)
Ein {{editprotected}} in einen VP zu setzen ist Missbrauch dieses Templates. Auch wenn ein Abschied natürlich traurig ist nicht angebracht.    FDMS  4    22:04, 19 August 2014 (UTC)
Sollte nun behoben sein. Kann bis zu 24h dauern, bis die Korrektur sichtbar wird. Übrigens, Perhelion, der uselang-hack wurde anno dazumal angewendet, weil es damals die einzige Möglichkeit war, überhaupt das normale Hochladeformular anzupassen und umzubauen. Lupo 22:15, 19 August 2014 (UTC)
Komisch; kein Edit-Conflict mit Perhelions Kommentar unten. Lupo 22:18, 19 August 2014 (UTC)
Das ist der liquide Übergang zum kommenden Liquid-Thread.:-P Ne das habe ich auch schon letztens bemerkt, das muss eine neue Technik sein, da wurde sogar ein automatisches "(BK)" auf deWP eingefügt. PS: Danke fürs Ändern bzw. der Info. GN8zZz User: Perhelion (Commons: = crap?)22:25, 19 August 2014 (UTC)
Das war ein Wink mit dem Zaunpfahl, da sich kein Admin berufen fühlt (warum sollte das ein Missbrauch sein?), wie oben besagte Textseite zu ändern zu verschieben oder sonstwas zu machen.[9] Die Textstelle wird wohl eher nicht auf Translatewiki liegen!? User: Perhelion (Commons: = crap?)22:12, 19 August 2014 (UTC)
Zumindest im Translatewiki hab ich den Text mal korrigiert. Ob das hier Auswirkungen hat … wer weiß? 2009, als du anscheinend angefangen hast, hatte ich aber schon fast alle Rechte und Verpflichtungen, die ich jetzt auch mit mir herumtrage. Commons war ein langer Schritt. Grüße, —DerHexer (Talk) 17:42, 20 August 2014 (UTC)
Meines Wissens sind die uselang-hack-Messages eben nicht in translatewiki. Das hiesse dann ja auch, dass die MediaWiki-Software irgendwo eine deownwork-Sprachdatei haben müsste. Die gibt es aber nicht: [10]. Es ist halt ein Hack. Lupo 21:50, 20 August 2014 (UTC)
Wie auch immer, zur Zeit sieht es gut aus, alles in deutsch. Gruss --Nightflyer (talk) 21:58, 20 August 2014 (UTC)

Hochladen von Museums Modells verboten (Philae/Rosetta)[edit]

Hello, Mein deutsch ist nicht am bestens ... Ich habe das teknisches Modell von Philae (Lander der Raumsonden Rosetta) photographiert . Dieses Modell wurde auf dem Messestand des Deutsches Zentrum für Luft- und Raumfahrt (DLR) präsentiert (Le Bourget 2013 Messe). Ich glaube das dieses Modell ist ein deutsches produktion. Es ist ein technisches modell (Maßstab 1:1). Aber dieses Bild wurde von administrator gelöscht (Commons:Deletion requests/Models of the Philae lander) (Grund angegeben : derivative models probably copyrighted as works of art). Ich bat um eine Wiederherstellung ... umsonst. Ich denke, es ist Verwirrung zwischen Geschäftsmodelle (Spielzeug,....) und museumsmodelle. Illustrationen von Tausenden von Artikeln sind bedroht. Was denken Sie? Danke. --Pline (talk) 10:48, 17 August 2014 (UTC)

Bilderspende von über 40.000 Siegelmarken[edit]

Wikimedia Deutschland wurde eine Bilderspende von über 40.000 historischen und gemeinfreien Siegelmarken aus dem Archiv von veikkos.com zur Verfügung gestellt. Sie sollen in Kürze zu Commons übertragen werden. Anmerkungen und Vorschläge für den Upload und insbesondere die Kategorisierung können auf der Projektseite hinterlassen werden. --Nicolas Rück (WMDE) (talk) 08:42, 18 August 2014 (UTC)

CC-Lizenztextlesung - Juristen und Pädagogen erkären die Creative Commons Lizenzen[edit]

Veranstaltung am 02.09.2014 in Berlin und im Livestream, Einzelheiten unter [11]. --4028mdk09 (talk) 22:08, 20 August 2014 (UTC)