Open main menu

Wikimedia Commons β

Commons:Administrators' noticeboard

(Redirected from Commons:AN)

Shortcut: COM:AN

Community portal
introduction
Help desk Village pump
copyrightproposals
Administrators' noticeboard
vandalismuser problemsblocks and protections

This is a place where users can communicate with administrators, or administrators with one another. You can report vandalism, problematic users, or anything else that needs an administrator's intervention. Do not report child pornography or other potentially illegal content here; e-mail legal-reports@wikimedia.org instead. If reporting threatened harm to self or others also email emergency@wikimedia.org.

Vandalism
[new report]
User problems
[new report]
Blocks and protections
[new report]
Other
[new section]

Report users for clear cases of vandalism. Block requests for any other reason should be reported to the blocks and protections noticeboard.


Report disputes with users that require administrator assistance. Further steps are listed at resolve disputes.


Reports that do not suit the vandalism noticeboard may be reported here. Requests for page protection/unprotection could also be requested here.


Other reports that require administrator assistance which do not fit in any of the previous three noticeboards may be reported here. Requests for history merging or splitting should be filed at COM:HMS.


Archives
12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1
70, 69, 68, 67, 66, 65, 64, 63, 62, 61, 60, 59, 58, 57, 56, 55, 54, 53, 52, 51, 50, 49, 48, 47, 46, 45, 44, 43, 42, 41, 40, 39, 38, 37, 36, 35, 34, 33, 32, 31, 30, 29, 28, 27, 26, 25, 24, 23, 22, 21, 20, 19, 18, 17, 16, 15, 14, 13, 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1
24, 23, 22, 21, 20, 19, 18, 17, 16, 15, 14, 13, 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1
71, 70, 69, 68, 67, 66, 65, 64, 63, 62, 61, 60, 59, 58, 57, 56, 55, 54, 53, 52, 51, 50, 49, 48, 47, 46, 45, 44, 43, 42, 41, 40, 39, 38, 37, 36, 35, 34, 33, 32, 31, 30, 29, 28, 27, 26, 25, 24, 23, 22, 21, 20, 19, 18, 17, 16, 15, 14, 13, 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1
Commons discussion pages (index)


Template:PD-old-assumed - a draft notice is requiredEdit

As per the discussion above, now archived, this template is not supported by policy and a bureaucrat closed Jcb's proposal from last year with the requirement that an RFC is required to establish policies and consensus on the detail of implementation.

Unfortunately as Jcb has sysop-only protected the template, I cannot restore the "DO NOT USE THIS TEMPLATE YET" sign that was clearly displayed until the time the proposal was closed. Archive link.

Could an administrator either reduce the page protection so that I can make the necessary changes to ensure this template is not used in error (as it has been example), or mark the template as being in draft status until an RFC is created.

I am going to take the opportunity to give Jcb a friendly trout, for using the archive of AN as evidence that other admins support this template and implicitly agree with implementing his proposal without the required community consensus on details.Diff

Thanks -- (talk) 22:46, 13 February 2018 (UTC)

Hi, Excuse me but I think Jcb is right here. In the last vote about this, I see 15 votes for 120 years (including yours) and 5 for 130 years.
Now, we need to write the documentation for the template and some information for Commons:Cut-off date for PD-old files. Regards, Yann (talk) 08:15, 14 February 2018 (UTC)
The template is being misused as a license because Jcb made it official before any details are written or agreed. It is being incorrectly used for works where PD-old-70-1923 applies, it is being incorrectly used where photographers are unknown. It should remain marked as not in use until the way it may replace other agreed licenses are explicitly defined for users. -- (talk) 08:34, 14 February 2018 (UTC)
If I understand correctly, we just have to officialise the usage of the template? (which I admit to have used for old photographs with unknown author - which can be of course be published with a less protective template… but this is another history) In the template page, some improvements have been proposed, like a "creation date" and a "copyright term" for countries where the term is different than 70 years PMA. --Ruthven (msg) 09:20, 14 February 2018 (UTC)
There's more than tidying up the template. The closure of Commons:Village_pump/Copyright/Archive/2017/03#Cut-off_date_for_PD-old that has been referred to here, requires that a detailed policy or guideline for how this new license is to be used and worked with existing PD-old and PD-unknown templates is made clear. I imagine that will end up with a workflow chart showing how to pick the right template and what evidence is required for users (and new users) to follow rather than long texts.
There are even undiscussed complex issues of how we swap this template for more legally meaningful templates (like PD-old-70) as soon as the original work is the correct age for them to apply.
Until these requirements are addressed, the template should not be in use. As can be seen by current usage in 260 images, it is certain to be incorrectly used.
Keep in mind that this "license" is not supported by copyright law. We have a duty of care to ensure that no reusers are misled by what this template means. -- (talk) 09:44, 14 February 2018 (UTC)
Well, the template is supported by common sense, but this seems to be lacking on Commons... Regards, Yann (talk) 10:25, 14 February 2018 (UTC)
It is indeed misuse in some places. I am correcting them right now. But do not throw the baby with the bathwater... Regards, Yann (talk) 13:15, 14 February 2018 (UTC)
@Yann: Can you at least warn the people that misused it?   — Jeff G. ツ please ping or talk to me 13:19, 14 February 2018 (UTC)
It was used for 18th and older works of art presumably because the author is unknown. Obviously, in these cases, the author died more than a hundred years ago, so PD-old-100 should be used. So yes, but unfortunately, in this case, the uploader is not reachable. Regards, Yann (talk) 13:41, 14 February 2018 (UTC)
@Yann: Very strange, it seems that case's uploader has disappeared from the publicly-visible database, as if its row was dropped.   — Jeff G. ツ please ping or talk to me 13:53, 14 February 2018 (UTC)
Apparently, this is the result of meta:Steward requests/Username changes/2018-02#MichellevanLanschot. The file log and file description history looked correct, but the "File history" section on the file description page didn't update until I purged its cache. LX (talk, contribs) 14:53, 14 February 2018 (UTC)
All files which use wrongly this template are from the same GLAM import, but by different users: Category:Media from Erfgoedcentrum Rozet. It is the whole GLAM project which should be informed. Regards, Yann (talk) 15:23, 14 February 2018 (UTC)
Just a prompt that when the author/photographer is unknown and there is no reason given for significant doubt that they can become known through reasonable enquiry, this template should never be used, regardless of whether it was created in the 18th, 19th or 20th century.
The rule of thumb should be that this template may become a statement of consensus once there is an RFC, but will never be a legally meaningful release statement that reusers can truly rely on. It's similar to giving a rubber stamp of "no copyright known". Where a legally meaningful release statement or license can be justified, it should always take precedence or replace this template. -- (talk) 15:06, 14 February 2018 (UTC)
I agree with you that a more precise release statement or license would be better, but IMHO, seeing the amont of undetected copyright violations or wrongly licensed files on Commons, you give to much weight to our license statements. Just my 2 Rs. Regards, Yann (talk) 15:28, 14 February 2018 (UTC)
Others uploading copyvios is not a reason to skip having proper policies and well written templates for copyright releases.
It becomes critical when uploading 100,000 images using a fixed rule for licences. My uploads this week User:Fæ/LOC are a good example, there are five different types of license that are automatically applied depending on date and collection type. Their use is precise and highly accurate in order to avoid future mass deletions such as have occured on Library of Congress collections in the past (e.g. WW1 posters published in Germany). If our policies and guidelines are missing or wooly, then frankly, I would advise GLAMs and other large scale mass uploaders to not upload any content that relies on associated templates, as these are likely to bite them or embarrass their organization later. -- (talk) 15:41, 14 February 2018 (UTC)
I only now noticed that this template is currently being questioned. As far as I see it, this template is an important step towards more "honest" public domain notices, as in the past, often "PD-old-70" or "PD-old-100" was simply assumed due to the age of an image, without knowing the author's year of death and where it's theoretically still possible that they died less than 70 (100) years ago. For example, Yann changed {{PD-old-assumed}} in File:Jakob Joseph Matthys StUrsenkalender 1.png to ({{PD-Art|PD-old-70-1923}}), I then changed it to {{PD-Art-two|1=PD-old-assumed|2=PD-1923}} (before reading this discussion). It's an image published in 1872 in Switzerland. I wouldn't use {{PD-Switzerland-old-unknown}} because this is only for cases where it's known that the author is unknown (as the notice in fine print says, "this applies only if a reliable source is cited to indicate that the author is not publicly known; just not knowing who the author is is not enough to qualify the image as public domain"). It's a misuse of this template and similar templates such as {{PD-anon-70-EU}} if used on images where the uploader simply didn't see an author mentioned in the source. It's also an inappropriate use of PD-old-70 templates to apply them to images where the author (currently unknown to us) very well could have died less than 70 years ago. The author of an image published in 1872 could have been born e.g. in 1850 and died in 1950. It's not very likely, but not impossible. Therefore, it is, in such cases, a reasonable assumption to treat the image as public domain - but we should, in all honesty, state that it is only an assumption. And that's exactly what {{PD-old-assumed}} does. Gestumblindi (talk) 00:13, 15 February 2018 (UTC)
I don't know where "reliable source is cited to indicate that the author is not publicly known" is stated, but that is not required by copyright law and it should be removed. The only requirement is that we make "reasonable" attempts to discover the author/photographer name if the file remains hosted on Wikimedia Commons. It is a serious mistake for Wikimedia Commons to start writing guidelines or templates which do significantly more than the law requires.
There are by now probably well in excess of a million historical photographs on Commons where the photographer is unknown and it would be literally impossible, or rather stupid given the context, to find a reliable source that states in print that the photographer is "unknown". They are unknown, because they are unknown and remain unknown after what any judge or magistrate would say was a reasonable attempt to find records. -- (talk) 11:22, 15 February 2018 (UTC)
@: "Reliable source ..." is stated in {{PD-Switzerland-old-unknown}} and there is similar wording in other "anonymous work" templates. {{PD-anon-70-EU}} states "Please use this template only if the author never claimed authorship or his/her authorship never became public in any other way". In theory, this is a requirement that's very hard to fulfil, because I might be able to say that I found no author in the source I used for an image, and not in source X, Y, and Z - but that still is no proof that the "author never claimed authorship". There is also {{PD-EU-no author disclosure}} which really seems redundant (same thing as PD-anon-70-EU with different wording, isn't it?)... I'm not quite sure where these statements originally come from, but e.g. in Germany, according to de:Anonymes Werk (Urheberrecht), the protection of anonymous works falls back to 70 years p.m.a. as soon as the author or their heirs disclose authorship. Gestumblindi (talk) 21:42, 15 February 2018 (UTC)

Edit requestEdit

Hi. I placed an edit request at File:Flag of Thailand.svg, but no one seems to have seen it. There's also quite a backlog at Category:Commons protected edit requests. --Paul_012 (talk) 08:03, 14 February 2018 (UTC)

✓ Done I changed the protection. Yann (talk) 09:15, 14 February 2018 (UTC)
I already uploaded the flag. -- User: Perhelion 09:23, 14 February 2018 (UTC)
@Yann, Paul 012, Zscout370: I added the upload protection again... (as reverted again, "high traffic", this absolute simple file has now 20 versions). -- User: Perhelion 11:15, 15 February 2018 (UTC)

Module:File needs updateEdit

Module:File needs an update regarding MP3, i.e. this must be moved upwards from not supported to fully supported file types. BTW also the MIME type for MP4 is wrong – at least it should be video/mp4, but I do not know which one is used by Mediawiki. (The right one actually depends on video, iana.org: video/mp4, or audio, iana.org: audio/mp4.) — Speravir – 00:34, 16 February 2018 (UTC)

Jarekt, you are the last admin who edited the file. I assume you know what to do. (It is in the moment protected for non-admins). — Speravir – 19:48, 16 February 2018 (UTC)
Speravir I am just about to take off for the weekend to a place without web access. I can look at this on Tuesday. However I am quite unfamiliar with this module and what is it useful for, so it might be better is some more familiar tackles it. Edit can be requested with {{editprotected}}. How does the current issue manifest itself? --Jarekt (talk) 19:56, 16 February 2018 (UTC)
@Speravir, Verdy p: The order of the file types seems irrelevant, so the change would be only code cosmetic (to the inline code comments).
@MP4: that seems simply true, so I fulfilled your request.
✓ Done -- User: Perhelion 20:21, 16 February 2018 (UTC)
@Perhelion: True, this is an array indexed by unique key, so the order is just there because of the comments above lines, and they are preferably sorted alphabetically in each group to avoid creating duplicate keys by accident. It seems that MP3 are now supported (so your change), and that MP4 got a new default MIME type
But note that guessing effective MIME types from only the extension here, has always been fuzzy, especially for MPEG files that have various extensions when the true MIME type would require parsing the content to find relevant codecs, you may even have an MP3 audio in an "*.mp4" file, this is always a generic MPEG envelope parser that will be invoked to determine the effective content type of embedded streams, and the format of their associated codecs indicated inside the header of each embedded stream by a "4-letter codes"; many players won't complain and will play correctly even an *.ogg file or *.wmp file even if it contains a MP4 video stream or MP3 audio stream, and not necessarily the MPEG enveloppe format for embedding streams.
Think about it: there are tons of possible codecs which can be embedded in various envelope formats, including MP3 audio within an OGG envelope format for a file named "*.oga", or WMP4 video stream within an MPEG envelope format for a file named "*.mp3" ! Guessing on file-extensions just gives an idea of what kind of envelope format parsers with can use to detect streams inside and their respective format/codecs to use. Many players now ignore these extensions (and don't have a suitable MIME type from the filesystem where they are stored) and will first parse the magic headers in file headers to detect the actual envelope format, and then select a relevant "demuxer", and then will enumerate the streams detected by the "demuxer" and their respective headers to know which kind they are in order to select the actual codec to read it, and then will build a synchronization object to play all these streams together according to their mutual synchronization points (such as timecodes), or process only some of the streams (e.g. language selectors for audio and subtitle streams, or only one of the alternate streams at different encoding rates/quality that the renderer can support, or only some audio streams if the renderer cannot support 5.1 channels and will only render stereo).
MPEG codecs are a mess, many possible codecs are protected by IP rights and patents (e.g. AALC). You may still have an "*.mp3" file containing some MPEG envelope, but using a patented and restricted codec for its audio streams, not really encoded in MP3 but in WMA!
What we really support if not file types, or MPEG envelope format (via the standard MPEG "demuxer", but individual stream formats (i.e. individual codecs identified by their 4-letter code in their own header).
And several stream formats in MPEG envelope have severe privacy and security issues (they can contain active streams with scripts, and if they are run, they will "phone home" to some external parties.
I'm not sure that the MPEG demuxer used in Commons can filter out from the envelope the streams using unsupported or undesired stream types (e.g. remove the additional 5.1 channels, or scripted channels, or "unknown" stream types), to keep only the streams we support and reduce the total filesize. This can be a security and privacy risk if we accept to host "MP3" and "MP4" files. We should see all MPEG (and even OGG) multimedia formats as if they were a "ZIP" archive containing multiple files with arbitrary MIME types, including executable code. verdy_p (talk) 20:43, 16 February 2018 (UTC)
Thx, Perhelion. Verdy p, maybe I misunderstand your novel, but at least Firefox does look on the submitted MIME type (e.g. if you understand German, read this: Video-Format oder MIME-Typ wird nicht unterstützt). And in Commons we all should know, that the file extension is not reliable: https://commons.wikimedia.org/wiki/File:Example.png (intentional external variant) does link to the file description page and has content-type: text/html, only with https://upload.wikimedia.org/wikipedia/commons/7/70/Example.png you get content-type: image/png and the actual image. On the other hand both Apache and nginx have a mime.types file in their configuration for mapping “Internet media types to unique file extension(s)” (cite from Apache’s mime.types file). Regarding MP3 it seems you missed that it is meanwhile accepted as file type on Commons, this is the reason for my request – I just additionally noticed the MP4 issue. — Speravir – 21:43, 16 February 2018 (UTC)
What I say is that the submitted MIME type is not even more relevant than the submitted filename if we don't actually parse the content (at least the envelope format to check if it has the correcct signature for the envelope, and then to enumerate the streams types it contains) to see if it really matches the submitted MIME type, and even when it does, if it includes unsupported streams (active scripts in some streams, or codecs with IP restrictions).. verdy_p (talk) 22:47, 16 February 2018 (UTC)
I wonder if Commons supports an antiviral scanner (clamav ?) to check for malicious multimedia types that could have been submitted with falsified MIME type or file names, if we want to avoid hosting these files and helping to distribute them to the net. The envelope format may be valid (conformant) but still if we accept random unknown streams in them, these files can be used as vectors. Even javascripts embedded in SVG may be used now as vectors; same remark about PDFs, or Office documents (including .odt) ! I don't care much what the user's browser will do (we cannot control which browser or version our visitors will be using, it's not the best placement and we must be proactive by checking files we host, the same way that we are active are checking IP rights and copyvios to remove illegal contents, we can also inspect files technically to detect if they are what they are supposed to be). verdy_p (talk) 22:52, 16 February 2018 (UTC)

Global blacklist discussion about .club, .space, .websiteEdit

Seeking the community's opinion on the usefulness and ready availability to utilise links to the top level domains

  • .club
  • .space
  • .website

Due to the amount of spam activity featuring these websites (spambot and some user), there is a general conversation about the usefulness of these three top level domains for the Wikimedia sites. Discussion at m:Talk:Spam_blacklist#Thoughts_about_blacklisting_.club/_.space/_and_.website/

If there is useful feedback for the global community, please add it to that discussion. Thanks.  — billinghurst sDrewth 01:12, 16 February 2018 (UTC)

Really low quality pictures from football gamesEdit

Hi, could someone please check these uploads by the user MYS77. Most of them have a really low, blurry quality. The user also adds them to their wiki articles, for example this one. It’s nice that the user tries to upload missing pictures of players but I don’t think there is any additional value for wiki users with this quality (on the contrary). Can an admin contact him about it, please? Thanks in advance! --Abu-Dun (talk) 15:06, 16 February 2018 (UTC)

@Abu-Dun: Where can I place my bets on these being cropped from stills of television broadcasts? - Alexis Jazz 16:15, 16 February 2018 (UTC)
@Alexis Jazz: According to his en.Wikipedia profile he is based (or at least born) in Brazil. This or this for example could be taken from a seat in the stadium and heavily zoomed in afterwards. They also have EXIF data (Sony Xperia M2 Aqua D2403). But I also don’t want to rule out your version. --Abu-Dun (talk) 16:48, 16 February 2018 (UTC)
@Abu-Dun: I hadn’t noticed the EXIF, so I stand corrected. Many are taken with that Sony phone, some of the older ones with a Motorola XT305 phone. For the PNG images there is no way to tell, he probably cropped them and the EXIF got lost when he saved them as PNG. As long as there is no better image available of the people depicted, I see no problem. In fact, I’d hereby like to applaud MYS77 for adding images of people we have no image of yet. A blurry picture still beats no picture. - Alexis Jazz 17:58, 16 February 2018 (UTC)
@Alexis Jazz: So this picture for example is useful in the infobox for the reader of the article? I definitely don’t think so at all. --Abu-Dun (talk) 18:31, 16 February 2018 (UTC)
@Abu-Dun: It’s not great, not so much because of the quality but because we are looking at the back of his head. Despite that, I disagree with you: it beats having no picture. It should be replaced as soon as a better picture becomes available. - Alexis Jazz 18:37, 16 February 2018 (UTC)

And now he is putting them back into the articles... see here. --Abu-Dun (talk) 09:30, 18 February 2018 (UTC)

@Abu-Dun: I do admit that some, like that one, don't really help. File:Serginho vs Sao Bernardo-30 01 16.jpg at least shows something and I prefer that over no picture. On File:Santos vs Vitória - Daniel Guedes.jpg I can't even really see any of his skin. And it has strange artifacts. I'll leave him a message on his talk page. - Alexis Jazz 09:40, 18 February 2018 (UTC)
@Alexis Jazz: Thanks! Have a great Sunday. --Abu-Dun (talk) 11:01, 18 February 2018 (UTC)

Image uploaded on top of another and both are mixed up.Edit

I was reported this really weird case of a file uploaded on top of another by an anonymous user on my discussion page. I copy his message here as I think one needs admin-right to solve this:

File:Necromanis_franconica.jpg - a different file has been uploaded on top of the old one. That causes a mismatch in mt.wikipedia, which uses the old file via a local copy under that name. The mt-copy could be deleted, if the old file would reappear in commons. Since 2016 several Wikipedias display an image that never was intended there. Could you re-upload the new file as File:Comparison - Sansanosmilus palmidens - Necromanis franconica.jpg and restore the old one? 85.182.86.148 15:09, 31 January 2018 (UTC)

Thanks! -- Michael F. Schönitzer 20:42, 16 February 2018 (UTC)

It's a bit unfortunate that this was reported so late. The original file has been overwritten, contrary to our policy, in 2016. --Túrelio (talk) 21:52, 16 February 2018 (UTC)
Michael, see COM:SPLIT, I’ve added a request. @Apokryltaros: Never do do this again, please! Cf. COM:OVERWRITE. — Speravir – 22:05, 16 February 2018 (UTC)

Another example, and my intuition suggests that more can be found. Incnis Mrsi (talk) 22:06, 16 February 2018 (UTC)

Yes, there are more. In Special:ListFiles/Apokryltaros every file which has not the upload comment “User created page with UploadWizard” should be checked. — Speravir – 23:18, 16 February 2018 (UTC)
I looked at them all and those are the overwritten images I found:
I did not include here images where only the colors where changed slightly. A few of the above could be considers smaller changes but I would split them all. -- Michael F. Schönitzer 00:49, 17 February 2018 (UTC)

RenamingEdit

Made a mistake with renaming process Category:Marie (ship, 1991). Found out later that it is Category:Maria (ship, 1991, Falkenberg) --Stunteltje (talk) 15:26, 18 February 2018 (UTC)

I've fixed it. On that note, please do not move category pages using the "move" button as the content, i.e. the files, will stay in the old category if you do so. If you need a new category, please create the new page and then re-categorise the files to this new category. After that you may redirect the old category page. De728631 (talk) 17:59, 18 February 2018 (UTC)