This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

NoScript warning when trying to view full size photo

When I clicked on this photo I got a NoScript warning in Firefox "The resource could not be found. File not found: /v1/AUTH_mw/wikipedia-commons-local-public.2f/2/2f/Ford_A9745_NLGRF_photo_contact_sheet_%201976-05-11%20%20Gerald_Ford_Library%20.jpg ". With other images no problem. What is the cause? Wouter (talk) 05:30, 1 July 2015 (UTC)

Confirmed, Noscript in Firefox gives "NoScript filtered a potential cross-site scripting (XSS) attempt from https://commons.wikimedia.org." and a 404 page. Selecting "unsafe reload" to bypass XSS protection from NoScript options shows the image normally. Firefox 38.0.5, NoScript 2.6.9.27, Win7/x64. Note that wikimedia.org is on my NoScript whitelist. MKFI (talk) 06:23, 1 July 2015 (UTC)

It sounds like noscript is replacing brackets in the image name with spaces, which unsurprisingly causes the image not to be found. I have no idea why noscript would do that. Bawolff (talk) 08:00, 1 July 2015 (UTC)

We had this with a custom gadget on de:Wikipedia:Technik/Archiv/2013#NoScript_meldet_Cross-Site-Script-Versuch in 2013. -- Rillke^(q?) 08:11, 1 July 2015 (UTC)

Commons logo

The Commons logo in the corner is blurry. Crisper versions are available.

The PNG version of the logo also has other issues: a bump right where the outer ring turns into the arrow, and variable spacing b/t the arrow tips and the red circle. But the fuzziness is most noticeable. Is the simplest solution just replacing it with a crisper PNG? --SJ + 06:07, 30 June 2015 (UTC)

It is suggested to use the .svg logo, not the png. --Steinsplitter (talk) 10:11, 30 June 2015 (UTC)

@Sj and Steinsplitter: The best was to resolve this problem is to convert the crisper .png, to a .svg image, "Convert. That was easy." From the friendly, Doorknob 747 (talk) 22:19, 30 June 2015 (UTC) :D

fixed. -- Tuválkin ✉ ✇ 21:50, 1 July 2015 (UTC)

Pulled the plug on CategorizationBot & ErfgoedBot

I've been running these two bots for a while. Both still run on old pywikibot compat code that will break soon. I could invest time in updating these bots and I have been considering doing that for quite some time, but I realized I just don't have the motivation for it. Commons has become a toxic place dominated by a small group of very vocal users. These users don't seem to accept that Russavia is banned and to try to turn everything into "Commons community" vs "WMF" battle. I don't identify with that and I don't feel like investing time in a project where this behavior is acceptable. Multichill (talk) 10:40, 28 June 2015 (UTC)

@Multichill: I don't think that commons is a toxic place, there are a lot of volunteers doing very hard work (which never participating in AN discussion). I also fail to see a "Commons community" vs "WMF" battle. I am highly disappointed by your statement here and i think under this circumstances you should also step back your sysop bit. Best --Steinsplitter (talk) 11:48, 28 June 2015 (UTC)

I am rather surprised that someone feels Commons is a toxic environment but I can empathize because I feel the exact same way about the English Wikipedia. I understand not wanting to make the investment of time to recode the bots but I thank you for the effort you went through to do it this long. I have found in the past that taking a break often helps me feel differently about things and have found in the past that when I stopped doing something or "retired" I missed working on the project and came back. I also don't really see the "Commons community" vs "WMF" battle but I do see that the WMF periodically oversteps their authority and does things counter to what the community wants simply because they can and because its more convenient for them. Some members of both communities feel like they don't need the other when these projects cannot succeed without mutual cooperation between the communities and the WMF. IMO the Russavia case illustrates that disassociation. Most of the time the WMF won't help the projects when asked to do so but then when it wants to do something it does it, violating any previous statements it made to the contrary. Reguyla (talk) 13:10, 28 June 2015 (UTC)

Sorry to read this, Multichill; I was brought to this link by your post on the mailing list. What a shame that others had to make comments that entirely prove you right. Risker (talk) 14:17, 28 June 2015 (UTC)
Risker, you have contributed to Commons on 4 occasions this year, and uploaded a total of 4 images in the 8 years of your account history. A part of having open discussion on Commons is that we regularly see people parachute in who seem to enjoy stirring up drama, are highly vocal off-wiki or off-project (as I know you to be), and dictate to long term contributors that we are terrible people for devoting our unpaid volunteer time here for the benefit of open knowledge. Many of us hide out on IRC and discuss issues on closed channels rather than risking becoming target of these sorts of unpleasant types of griefing. If you want to do something positive for Commons, take part in one of our projects for a while, and use that experience to form a solid evidence-based opinion on how our community works and how it can improve. --Fæ (talk) 14:36, 28 June 2015 (UTC)

Yes, I know, Fae. I do not normally participate here because of my earliest interactions in which I was treated rudely and (in at least one early case) in a manner worse than I've ever been treated on English Wikipedia, which ironically I consider to be a pretty unpleasant place for a lot of users - it's the one thing Reguyla and I will agree about. I'm not a photographer, and I'm not looking elsewhere on the internet for images or other media; this wouldn't ever be my home. I do, however, care a lot about developers, oddly enough. I do care when people who have built useful tools that help the entire Wikimedia community feel that they're no longer valued. I'm shocked that the first reaction to his post was "please hand in your sysop bit". I'd hope you be shocked too. Risker (talk) 14:50, 28 June 2015 (UTC)

@Risker: I am disappointed by your comment :-(. Why you put oil in the fire? There might be some toxic users here, but there are also toxic users on enwp, dewp and other wikis. Calling a project "toxic" (putting all users under the same umbrella) is very immature. It is hurting to see Multichil, a commons admin, talking so bad about commons. I applicate his botwork and it is sad to see that he does not port his bots to core. If he really thinks that commons is so bad, he should probably step back his sysop bit or doing something to make commons better. But such "commons is toxic" posts are imho not helpful at all. It is not fair to call commons toxic. Commons is a wonderful place with a lot of hardworking users, and it is always a pleasure to work together with other users here on commons. --Steinsplitter (talk) 15:54, 28 June 2015 (UTC)

Thanks for your work Multichill. @Risker: shame yourself for your attempt to start a flame war. --Denniss (talk) 14:22, 28 June 2015 (UTC)

Sorry about that; it was not my intention to start a flame war, which frankly I think started with the first post. I am actually quite shocked that the first two comments are defending the atmosphere that Multichill finds distressing instead of "sorry to see you're not happy here, would you be willing to share your code with another developer can look at making the necessary changes?" That's what I'd really hope to see. If the work these two bots have been doing is valued by the Commons community (and given they have made a combined 1.92 million edits, I suspect their work has been useful), I'd hope that the Commons community would focus (a) on trying to find a way to continue the work of the bots, for its sake and (b) simply express sorrow that a longstanding member of the community has chosen to leave, instead of asking for them to completely disassociate with the project. (Seriously, asking for his sysop bit?) Risker (talk) 14:41, 28 June 2015 (UTC)

Emotionally colouring/escalating this thread by introducing words like "distress" and "shocked" does not help show your intention is to avoid creating drama. Could you confirm which email discussion you referenced that directed you here? It does not appear to be one of the open lists I am subscribed to. --Fæ (talk) 14:57, 28 June 2015 (UTC)

The mailing list is wikitech-L, which is a public list. Thread is "API BREAKING CHANGE: Default continuation mode for action=query will change at the end of this month". Risker (talk) 15:05, 28 June 2015 (UTC)

Just to clarify, my post was not intended to flame anything but to thank them for their participation, encourage them to take a break and continue and to empathize for their feelings because I know how it feels from my time on ENWP. I would like to see at least some of the work done by these bots done by someone if not Multichill but I hope they change their mind. I also find it somewhat ironic that they blame this community for not being nicer to the WMF and then mentions 2 issues with his bots that are the direct result of actions by the WMF (although I admit they are for the long term good of the projects). I am also glad that me and Risker have some common ground. Reguyla (talk) 15:08, 28 June 2015 (UTC)

Thanks, for the record I see the link in this post this morning. I keep an eye on Labs-l but the tech list (and the IRC channel) is a bit too busy with so many different things I rarely try to follow them. --Fæ (talk) 15:15, 28 June 2015 (UTC)

@Multichill: thank you for your hard work. I completely agree with you and feeling much the same way, sadly it isn't a nice feeling to have when you've lost interest and motivation. Bidgee (talk) 16:17, 28 June 2015 (UTC)

I know how you feel Maarten... It's really, really, demotivating. And yes, en.wp isn't too much better. —TheDJ (talk • contribs) 19:07, 29 June 2015 (UTC)

Depending on who you ask, myself included, ENWP is far worse than Commons. I will say though that things are getting better now that some of the historically problematic admins are getting to the Judge, Jury and Executioner (AKA , the Arbcom). So things are looking up there. Reguyla (talk) 19:55, 29 June 2015 (UTC)

Thank God for this decision! Erfgoed bot will not be missed (by me, anyway).--Strainu (talk) 18:58, 28 June 2015 (UTC)

@Multichill: Do you have a source code repo for your bot's code and what is the main entry point. Is /data/project/catbot/readme.txt still up-to-date? Also, could you share what was set in cron? Thanks in advance. If it is on Tool labs, which free license did you choose for the source code? -- Rillke^(q?) 20:05, 28 June 2015 (UTC)

The cat script seems to be on labs and freely licensed (short test: seems broken). See grep -R "Please add categories to this image" /data/project/catbot/. On the other scripts i haven't seen a license :-(. --Steinsplitter (talk) 14:23, 29 June 2015 (UTC)

There is a general problem of bots and scripts which are widely used but not maintained properly (because the author is overstrained, tired, leaved the project or have some conflicts etc.). As regards ErfgoedBot, it is a very helpful tool but its development and maintenance appears to get freezed before years still. An example: ErfgoedBot updated daily a set of pages Commons:Monuments database/Unknown fields. However, its operator absolutely doesn't respond to reports about changes of field names in the affected templates. We cannot improve the templates nor correct their inaccuracies because WLM mill is not able to reflect the changes. I think, such important processes should be not so dependent on individuals and their fickleness. With all respect and gratitude for them. But I can't see inside where the problem springs from. --ŠJů (talk) 15:40, 1 July 2015 (UTC)

If someone writes a useful bot, and you find yourself running projects that rely on it, then you should feel free to ask the operator if they have shared the source code on github or similar. There have been several cases where we have tools and bots where this was never discussed and if a volunteer becomes seriously unwell, or is on a long wikibreak/seems retired for whatever reason, they are unlikely to find the time to cooperate. We should also encourage our most critical bots to have multiple operators and maintainers. This reduces the chance they will be unexpectedly lost and has the great benefit that the burden of maintenance is shared.

Lastly, as a ~~fickle and tired~~ bot operator I occasionally get thanked by users, but not very often. In fact far more often I get repeated complaints about things not working well, or chasing me about things that are out of my power to fix (like WMF server drop-outs!). If you use a bot, automated report or tool, and think to yourself how useful and neat it is, spend a few seconds by rewarding the operator with a barnstar to keep them sweet and engaged with the project. Bot operators are unpaid volunteers focused on the public good like everyone else.

--Fæ (talk) 16:43, 1 July 2015 (UTC)

Yes - regrettably, the best and most important work is usually accepted as matter of course. We appreciate it just when we lose it, or when it get to be insufficient. Maybe, we should express thanks explicitly more often. However, when someone's work is widely used and have amounts of its fruit, that can be also a powerful source of satisfaction – that was also my way to express my gratitude for Multichill's (and other's) work on WLM. Maybe, improvement requests can be also perceived as expression of appreciation and thanks? I hope, some programmers will be capable to help Multichill with his work, or to take his relay, or to mediate related conflicts? It would be a pity to leave a monument database and lists to perish. --ŠJů (talk) 14:46, 2 July 2015 (UTC)

Template:PD-NL-Gov/en depreciated or not ?

At Template talk:PD-NL-Gov/en is a 'kept' tag, while at Commons:Copyright_tags#Non-U.S._works under Netherlands it says it is depreciated. On Template:PD-NL-Gov/en it says: Images using the PD-NL-Gov tag need to be relicensed or deleted, as appropriate. To me it appears that if after a deletion request discussion it is decided it is 'kept', this would mean the template isn't depreciated. Do I understand this correctly ? Regards, --OSeveno (talk) 13:39, 29 June 2015 (UTC)

@OSeveno: They are not the same.. a template can be 'deprecated' (meaning it's no longer intended to be used) but 'kept' (because it has an unwieldy number of existing uses that need to be fixed, and deletion of the template would remove the ability to track them). In the case of this particular template, it was actually deleted after the original discussion, but then recreated later that same day as a 'deprecated' template, presumably after it was pointed out that it was in use. The 'kept' is misleading. As it stands now, the template is not intended to be used (but is linked quite a few times from old discussion). No files use it, and none should. Revent (talk) 16:10, 29 June 2015 (UTC)

(as a further note) The 'kept' on the talk page was added by a bot, when it noticed that the (recreated) page still existed after the discussion was closed. Revent (talk) 16:12, 29 June 2015 (UTC)

Thanks for clarifying that. Regards, --OSeveno (talk) 14:33, 2 July 2015 (UTC)

Batch upload advice

Hi there. I'm planning on tackling the batch upload request Commons:Batch uploading/Freshwater and Marine Image Bank. I'm looking for some advice on how to display various information from the files in the Information box. I moved my questions from here to the Batch Uploading page above. I appreciate any help or advice!

BMacZero (talk) 02:52, 3 July 2015 (UTC)

Preview shows an image wrongly rotated

I found that image that is strangely converted by image preview (but is correct in thumbnails): File:Gyaru-ikebukuro-aug2007.jpg You can see the effect on Category:Gyaru if you click on the image (Gyaru-ikebukuro-aug2007.jpg), it shows up rotated but with the original dimensions, so it's weirdly squeezed. I checked the Exif and there's no rotation, orientation is top-left as usual. Might be worth checking out? SilverbackNet^talk 19:22, 1 July 2015 (UTC)

The file has been rotated after upload but thumbnails seem to have not been updated properly. Purged. MKFI (talk) 06:22, 2 July 2015 (UTC)

I don't see anything wrong, except the dimension was changed from 650px → 640px with 0° rotation. ↔ User: Perhelion (Commons: = crap?) 17:57, 2 July 2015 (UTC)

@Steinsplitter: What do you mean? ↔ User: Perhelion (Commons: = crap?) 06:43, 3 July 2015 (UTC)

EXIF-Orientation has been fixed. Please note that MW is automatically rotating files based on EXIF-Oriantation. In raw-modus you see the the bot has worked correctly. --Steinsplitter (talk) 10:41, 3 July 2015 (UTC)

July 03

updated information suggest file name includes error

How do you fix a file name that communicates erroneous information? See [1]. --Smkolins (talk) 11:04, 3 July 2015 (UTC)

Have a look at Commons:File renaming, --Pristurus (talk) 11:14, 3 July 2015 (UTC)

Thanks --Smkolins (talk) 11:35, 3 July 2015 (UTC)

NASA picture

How can I tell the copyright on this amazing photo of a Chrysler turbine engine? I would love to upload it, but I cannot seem to determine what its copyright might be? Thanks for assistance, mr.choppers (talk)^-en- 01:48, 4 July 2015 (UTC)

It says the image was created by NASA so license tag should be {{PD-USGov-NASA}} Offnfopt^(talk) 02:22, 4 July 2015 (UTC)

July 04

Study reports that Wikimedia Commons media has large financial value

The Valuation of Unprotected Works: A Case Study of Public Domain Photographs on Wikipedia, the academic study
"'Free' Wikipedia photos worth at least $246 million a year, study says" from Fortune magazine

Blue Rasberry (talk) 18:02, 1 July 2015 (UTC)

Bluerasberry As with pretty much all "scientific" studies of Wikipedia, this one is complete rot. I strongly advice nobody on Wikimedia give this report any oxygen. The authors build a case by assuming many things that are patently untrue or seriously unlikely. Given that the paper is about "Public Domain", it is startling that their definition of this is completely wrong. They include CC-licensed works, saying "For the purposes of this paper, therefore, we include works which may be freely used under a Creative Commons license, even though in many cases the author technically retains title". There's no "technically" or "in many cases" about who retains "title". Claiming that works with a "free" licence are public domain, and that credit of authorship is merely a technicality is stupendously ignorant and disrespectful. They make further assumptions about how much Google increases traffic flow if a web page contains in image and how much a Wikipedia page is worth in terms of advertising revenue (I kid you not). At one point, when discussing novels becoming public domain and therefore sold at a cheaper price, they completely confuse "publisher" with "copyright owner" (i.e., author). I can only assume that Harvard Journal of Law & Technology is where C-grade term papers go to be archived, and shouldn't be confused with a serious academic publication. Sigh. -- Colin (talk) 18:44, 1 July 2015 (UTC)

Colin The paper at least demonstrates public interest in the value of Wikimedia content. If it is wrong then it gives the next researcher something to challenge. Blue Rasberry (talk) 19:18, 1 July 2015 (UTC)

When I read the list of assumptions in the paper half of them did not seem reasonable, so just like Colin I was taking the findings with a grain of salt; however I think it is a good start and the numbers are likely to be within of the right order of magnitude. Hopefully next iteration will get it closer. I always had a problem with estimations calculated by assuming dozen numbers with some huge or unknowable error bars and then multiplying them together to get your estimate. I am mostly interested in those error bars because that is what will tell me if the real value is likely to be off by 1%, 100% or 1000%. --Jarekt (talk) 17:10, 2 July 2015 (UTC)

Jarekt, I don't believe the figures are anywhere near the right order of magnitude because they ask us to imagine a world without PD and a world where Wikipedia is not a free content project that attracts freely licensed images and a world where Wikipedia's budget could pay for $250 million of photos per year (which is about five times WMF's entire annual budget). Their $250 million is naively worked out by taking the 2 million pages with free photos and multiplying that with the cost that Getty/Corbis charge to licence a single photo on a website for a year ($105-$117). Now I don't know where they get that licence figure from -- it often varies by the size of image you are licensing and quite possibly also by other factors like age or quality. The thing is that nobody who needs to licence 2 million images would pay the same unit cost as someone who licenses one. The incompetence of this economic mistake is staggering. (Getty own 80 million still images and annual revenue is $869 million -- there's no way 2 million thumbnail images licensed to a non-profit would bring in $250 million) And many images are sold for a great deal more than that for higher value purposes such as advertising. A world without public domain images or freely licensed images would much more heavily use photo agencies, so market forces means the price per image would also be less. And a Wikipedia that had to pay for images would undoubtedly licence 240px thumbnails rather than the multi-megapixel images that Commons actually hosts. Given the big stock photo corporations recent behaviour, I can well imagine them coming to a deal with Wikipedia that lets them use the small thumbnails for free, in return for a link on the file-description page that allowed viewers to see the high-resolution photo for a fee or to license it themselves. So in this world, without Commons, the cost of the images that Wikipedia uses is zero. $0. No error bars or orders of magnitude. Wikipedia pays nothing for the images. But there is no Commons for anyone else to use high resolution images. And you have to pay to look at any image in detail. How does someone put a price on how shit that world would be? -- Colin (talk) 18:57, 2 July 2015 (UTC)

If Commons didn't exist, most people would probably put their free images on some other site. There are already quite a lot on Flickr. --ghouston (talk) 23:20, 2 July 2015 (UTC)

Although some images from people who just want to put an image on a Wikipedia page, without caring much about license, probably wouldn't be CC licensed otherwise. --ghouston (talk) 23:25, 2 July 2015 (UTC)

--ghouston, they are imagining a world without free image content at all. So not just "no Commons" but "no CC anywhere". They aren't particularly interested in Wikipedia/Commons but in trying to put a value on the "public domain" (even though they completely misdefine it). They are only using Wikipedia as it is a publicly available source of information to mine. The two most disappointing things about this are that it is yet another study of Wikipedia / Free Content Project where the authors don't really understand the domain and that such a dire C-grade effort is being published at all. Have they never heard of Getty Embed -- 50 million images freely usable. What is most sad really, is the ideology that one needs to (or it even makes sense to) put a monetary value on things that are in the community (public domain images) or that are donated to the community (freely licensed images). -- Colin (talk) 07:31, 3 July 2015 (UTC)

Personally I think that study is overrated. We can see how much this site would be worth by looking at how much Wikia makes. Sure we get a bit more traffic, so add about 10 or 15% but its no where near the hundreds of millions they say in the study and we would lose a lot as well. If this site were for profit then that means the donations would stop and it would be taxed on what it makes. I heard that the WMF gets a little bit of a discount on IT services from the data warehouse they are using due to its ta free status so that would be lost too. A lot of the volunteers would leave and would need to be replaced by paid folks. So to me the whole study makes assumptions of things being equal when they would be far from equal in reality. Reguyla (talk) 00:30, 3 July 2015 (UTC)

Way back in the day there were several Spanish-speaking Wikipedians who forked and created en:Enciclopedia Libre to protest a proposal to make Wikipedia into a for-profit venture. We don't want that repeated. We can't do what the study proposes. WhisperToMe (talk) 08:38, 4 July 2015 (UTC)

Source information incorrect on an image

I was working on some images today and noticed that the source information on File:Don_J._Jenkins.jpg is incorrect. We have the description that this person is Bryan Battaglia, Senior Enlisted Advisor to the Chairman of the Joint Chiefs of Staff but its actually Don Jenkins the medal of Honor recipient. I noticed this because I know what they both look like in person and I knew this was not a picture of Bryan Battaglia. Otherwise I probably wouldn't have caught this. When I looked at the source for the photo it is also incorrect. My question here is, what are our procedures for correcting something like this? I can contact the DoD source and get that fixed, but I'm not sure how we would change it here to reflect the correct information. Reguyla (talk) 16:28, 3 July 2015 (UTC)

We'd change it by editing, just like anything else that gets corrected. I'm not sure what you think is difficult, so I can't give you anything more specific. - Jmabel ! talk 16:44, 3 July 2015 (UTC)
- Sorry for the misunderstanding, it wasn't a matter of not knowing how, I just wanted to make sure that it was appropriate since any change would not match the supporting source link. Reguyla (talk) 17:18, 3 July 2015 (UTC)
  - Presumably you will have some source for your change. Cite it. - Jmabel ! talk 19:57, 3 July 2015 (UTC)
    - Not for this one I don't other than anyone can look at the corresponding articles on ENWP and see that the image is not of Battaglia but of Jenkins. The group of images on Flickr all seem to refer to Battaglia even in the ones he isn't in and several have the exact same description, so I wanted to ask what should be done about that. Should we leave the incorrect description that was pulled in from the source, should we change it to reflect something more accurate or should we just leave it and maybe put a history statement or note saying that its wrong, but the description is actually X. Reguyla (talk) 20:55, 3 July 2015 (UTC)
      - I'd just replace the original description with a correct one. It will be easily verified as correct if there are other photos in Commons of the same person, or he's easily identified in a web image search. --ghouston (talk) 01:24, 4 July 2015 (UTC)
      - I think the photo shows Gary L. Littrell. Mrwojo (talk) 14:56, 4 July 2015 (UTC)
        I'd include "probably" or "possibly" in the description if there was any room for doubt. You could also put "possibly Don J. Jenkins or Gary L. Littrell". Other sources may list who was at the event. --ghouston (talk) 02:24, 5 July 2015 (UTC)

File transfer

I would like to use this image on the English Wikipedia for the page however since the file is hosted on the Hungarian Wikipedia (and I don't speak Hungarian) would it be possible for this to be transferred to the Commons? The C of E (talk) 12:53, 4 July 2015 (UTC)

Yes, you can load a copy of it here as public domain. The engraving was created/published in 1778 (based on an original in the UK National Portrait Gallery) and faithful reproductions of it are considered to have no additional copyright. It is possible to use bots to arrange transfer, but it's quicker for you to download and re-upload to Commons, just use the standard upload link and wizard. --Fæ (talk) 13:31, 4 July 2015 (UTC)

Conversion of still GIF images using color or transparency to PNG

So I have been running User:GifTagger for some time until it was blocked due to "Problem with the editing and the enforcement of an opinion without conversation with the relevant community" in January. I had to clean up the code and was too busy with other things that time anyway. Though, now I feel like getting a discussion up on this topic. I had some users on my talk page asking if I could fire the bot up again but I'd rather have any sort of feedback before getting blocked out of the blue again. --McZusatz (talk) 20:20, 17 June 2015 (UTC)

Just to start the discussion, I will present what I think are the advantages of using PNG over GIF:

The thumbnail of this gif is **useless** as it only shows some random black pixels. Sadly it was used in two articles.

Better thumbnails
C.f. thumb on the right; GIF thumbnails are often pixelated due to transparency (Only a single transparency index is supported). Also PNG thumbnails support 24-bit RGB in contrast to a maximum of 256 colors in GIF (thumbnail) files.
Smaller size
GIF files tend to be larger than PNG
Easier editing/"Lossless" editing
Someone may want to edit those files. Surely the editor prefers a 24-bit palette over the 8-bit GIF-palette without uploading a new PNG derivative file before or after his edit by fiddling with (partly) broken tools such as UpWiz or DerivativeFX. Also you can not apply most filters to indexed palettes which results in a lossy process: Palette -> 24 bit -> Apply filter -> another? Palette
However, the conversion from GIF to PNG is lossless and also the transparency, if present, does not get lost. (PNG supports 8-bit transparency in contrast to GIF's 1-bit transparency.)

--McZusatz (talk) 20:20, 17 June 2015 (UTC)

My opinion is to leave the GIFs as is and only update them on a needed basis. A large number of GIFs should be replaced by SVG (vector data) to begin with, so a extra PNG is unneeded in a large number of cases. Thumbnail point you made could be dealt with by generating PNG thumbnails with a anti-alias option instead of generating GIF thumbnails (i.e. similar to how we convert SVG to PNG for thumbnails/re-sizing). This is an issue that could be fixed through the wikimedia software end without having to re-upload a new version of every file. Offnfopt^(talk) 22:27, 17 June 2015 (UTC)

@McZusatz: One rationale I find hard to understand is (for example at File:Enrico cialdini.png): "This GIF was problematic due to non-greyscale color table." Isn't it correct for a colour image to have a non-greyscale colour table⁇ I'm not sure which of your other rationales may also apply, but the filesize was bigger than that of File:Enrico cialdini.gif. I'm also a little concerned that (non-admins) lose the edit history of the deleted files, so it's harder to check the licensing etc. --99of9 (talk) 06:25, 18 June 2015 (UTC)

99of9 After reading your comment, I went ahead and ran a small test case of some of the files in the contrib list for the bot. I don't have access to see the pages for the deleted files, so I converted the PNG files to GIFs using the exact same indexed palette found in the PNG, so there is no loss or change in the image from the conversion I did. The original GIF file sizes may be different from mine depending on what options they used to save the files, I didn't do any special optimizations or tweaks to the files. The below table is the results of this small test case. You can see from the table that the claim of PNG having a smaller file size did not hold up to this test case. Also as I stated before, the bulk of these images are better served being converted to vector graphics due to the nature the pictures. Offnfopt^(talk) 08:50, 18 June 2015 (UTC)

File	GIF size (in bytes)	PNG size (in bytes)	Smaller file size	PNGopt
File:Enis logo2.png	1,997	2,150	GIF
File:Enlarged lateral ventricles in schizophrenia.png	45,747	58,353	GIF	39.227
File:Enlarged spleen.png	10,106	10,960	GIF
File:Enlluita-logo.png	5,500	6,009	GIF
File:Enmascaramiento temporal.png	4,032	5,391	GIF
File:Enneagram - 2.png	30,934	31,843	GIF
File:Ennea triangle.png	1,139	2,161	GIF
File:Enrico cialdini.png	19,980	23,409	GIF	17.314
File:Enrin u0.png	13,577	20,241	GIF	11.227
File:Ensea-fonctions.png	7,854	7,815	PNG

I can agree Offnfopt and 99of9. The file size is only one point, as I mentioned to McZusatz before, the bot need a simple PNG optimizing function (I used the very fast PNGGauntlet). So I only vote for the bot if he has such functionaltiy. ↔ User: Perhelion (Commons: = crap?) 09:29, 18 June 2015 (UTC)

I replaced the poor PNG optimization with some better one in the meantime, so this should not be an issue any more. --McZusatz (talk) 10:11, 18 June 2015 (UTC)

@99of9, Offnfopt: Your proposal to use PNG for thumbnails instead of GIF, indeed solves the issues that can be observed in GIF thubnails today. Nonetheless, I'd still prefer to have the source image in PNG as well to make it easier for users to upload an enhanced version without going through quantization of the color values. This quantization degrades an image slightly if the color values don't match the quantization levels. --McZusatz (talk) 10:11, 18 June 2015 (UTC)

I want to add that I'm not against the bot per se, when I first posted I was in the mind set thinking the bot was going to leave the original GIF, so I was thinking it was going to cause a large number of duplicate files. But being that is not the case and letting the pros and cons rattle around in my head for a while, I'm warming up to the idea. Though I do worry about the bot encountering a file configuration it may not be able to handle and end up outputting a garbage PNG file and removing the original GIF. I wonder if the bot should generate a paged gallery log of files converted so others could keep an eye on the changes being made without having to scroll through the contrib log of the bot. I also support the good suggestion by Perhelion. Offnfopt^(talk) 10:29, 18 June 2015 (UTC)

There is https://commons.wikimedia.org/wiki/Special:ListFiles?limit=500&user=GifTagger&ilshowall=1 but I can also create a custom log page if you want me to. --McZusatz (talk) 14:42, 21 June 2015 (UTC)

@Billinghurst: If you have any issues with the Bot, please raise them. --McZusatz (talk) 14:42, 21 June 2015 (UTC)

@McZusatz: My issue was that the bot was deleting images, not that it was running an image generator. The bot and this community should not be overriding how the communities have placed and are managing their inclusions. Commons is a central repository, not a determinator. If a community has and chooses to use a gif, then leave their image alone, and just do your conversion. If you wish to discuss with the communities about your bot and its actions then start an RFC and invite these communities to join the conversation. The means exists. — billinghurst sDrewth 13:57, 27 June 2015 (UTC)

The "non-greyscale color table" bot comment is due to giving non-transparent greyscale GIFs lower priority for conversion (i.e. not to be replaced without a further round of discussion at a future date), because of the fact that PNG thumbnailing for many years was significantly worse at resizing opaque grayscale PNGs than GIF thumbnailing is at resizing opaque grayscale GIFs -- and also various developer comments which have led to suspicions that improving PNG resizing in this area is not a WMF priority, and in fact that the very belated partial progress which was finally made in such PNG resizing could actually be reversed if WMF developers choose to adopt image software with some nifty features in other areas. See the discussion at Commons:Bots/Requests/GifTagger... -- AnonMoos (talk) 12:32, 18 June 2015 (UTC)

I will again emphasise to administrators and bureaucrats that it is not the job of Commons to set the standard that the sister wikis use, nor to think that we impose componentry on these wikis, they are their own bosses. This is the central repository that is used by all the wikis to make the images available to all wikis. We determine that files are within copyright, and that the files are within scope. More than that should be taken up with the wikis where we asked for them to come and contribute not enforce our opinion from limited conversations, in limited corners of Wikimedia. — billinghurst sDrewth 14:07, 27 June 2015 (UTC)

FWIW, its really easy to make MediaWiki render non-animated gifs as PNG files, if there was wide agreement that that was the right thing to do. Bawolff (talk) 08:11, 2 July 2015 (UTC)

Imo there is no reason not to create PNG thumbnails of all still GIFs instead of obviously broken GIF thumbnails. --McZusatz (talk) 10:47, 2 July 2015 (UTC)

@AnonMoos: Would you oppose serving non-animaged greyscale GIF images as PNG thumbnails as well? --McZusatz (talk) 10:47, 2 July 2015 (UTC)

@AnonMoos and McZusatz: It still actually does not answer the intended reality of why that person actually edited/changed the images. But, in reality the Wikimedia rules or norms state the better the image, the better it is accepted in the Wiki community. Technically PNG images are always better than Gif images. Also, most Wikipedia chemistry articles have molecular arrangements as either a PNG or SVG image. So this person does have a point on the reason for converting it. But, I still do agree with the actions taken by the admins, for blocking the User since he/she should have talked or had a discussion before changing the images all of a sudden. @GifTagger: All wikis are communities were changes should be discussed before hand. From the friendly, Doorknob 747 (talk) 21:44, 5 July 2015 (UTC) :D

"taken with..."-Categories in the Categories of the camera manufacturers leads to heavy miscategorization

Hi, I see a problem concerning many categories below the Category:Photographs by camera manufacturer.
An instance: A ship in Taiwan file is Taken with Leica V-Lux 4, and therefore in the Category:Wetzlar, a town in Germany.

Why?

Category:Taken with Leica V-Lux 4 is in
- Category:Photos taken with Leica in
  - Category:Leica cameras in
    - Category:Leica that's a
      - Category:Companies based in Wetzlar located in
        Category:Wetzlar

2013 we had a discussion in the german Commons-forum and User:H-stt told me to remove the meta categories from the Camera categories, but over the years this was reverted and so did User:Ghouston on 27th of June with all the "taken with Leica"-Categories, although I inserted the {{Cat see also}}-Template in all categories.

I know, it's a problem in principle and so I wanted to hear your opinion about a solution. I won't act as an editwarrior, but I must admit that I am very unsatisfied with this situation. Kind regards, --Emha (talk) 11:51, 29 June 2015 (UTC)

I still believe that the appropriate solution is to delete each and every "taken with"-cat. They mess up the category system and destroy valuable search functions. A more gentle solution would be to keep those cats but remove their top-cats from the cat branch of the camera-cats. That is because these cats categorize images, not cameras, which is why they must not be in the camera-cats. --h-stt !? 11:57, 29 June 2015 (UTC)

I think this is a misunderstanding of the category system. The relationship between a parent category and its subcategories is not necessarily "is a type of" or "located at". Thus a picture of a Leica camera is not necessarily taken in Wetzlar. Maybe the camera was made there, or maybe not. The pictures taken by the Leica cameras are then one more step removed. This happens throughout the category system. For example, what does File:Gravity escapement.gif have to do with Category:St Albans Cathedral? It's actually in a subcategory via Category:Burials at Saint Albans Cathedral, Hertfordshire and Category:Edmund Beckett Denison. --ghouston (talk) 12:17, 29 June 2015 (UTC)

That's actually a huge problem: We currently have no means to define the kind of relation between a (sub-) category and it's mother-category. The result is a chaotic network that next to impossible to grasp for any search function. COM:Structured data, though aimed at meta data other than content description in it's initial phase, could provide us with the necessary tools to define different types of relationships. --El Grafo (talk) 12:32, 29 June 2015 (UTC)

(Edit conflict) That's a general problem of our category system. There are numerous other examples that do not include "taken with" categories – I remember pictures of tennis matches showing up in the Category:Aviation subtree because they took place in a stadium that was named after someone who was related to someone who was a pilot (or similar). Movin the "taken with" categories to a separate subtree wouldn't solve the issue. We'd have to dissect the whole category system into single branches of "by location", "by author/manufacturer/…", "by date/time/period", "by color", "by taxon/type/series…", "by ID", etc. and use a search function that is capable to do proper intersections. I'd say it's impossible to do a conversion like that on the fly, but conversion to COM:Structured data looks like the way to do it. Then we could finally get rid of stupid constructions like Category:Women by country by century by occupation as well. --El Grafo (talk) 12:24, 29 June 2015 (UTC)

Sorry about the conflict. Yes, there are really multiple categorisation schemes that are independent, such as subjects, dates and locations. Combining them into ad-hoc intersection categories gives weird things like the ones I mentioned at Commons:Village_pump/Archive/2013/10#Category_madness_in_Hong_Kong. --ghouston (talk) 12:33, 29 June 2015 (UTC)

(Edit conflict) Ghouston, have you ever read Commons:Categories? The branch Category:Image sources is different from the Category:Topics, the how was the image made is not the same as what does the image show.
To stay at the given instance: This page lists all new files uploaded in the Category:Mittelhessen (including Category:Wetzlar). It doesn't work anymore if a ship in Taiwan is listed there.
Please don't argue with other miscategorized files, I know that there are many, but I seek a solution for the given ones. Regards, --Emha (talk) 12:54, 29 June 2015 (UTC)

Well, image sources are where the images were taken from, and it seems a bit different to how images were made. Perhaps you could argue that "hidden" categories are only for maintenance and shouldn't be part of the Topics category tree. However there's no policy for that, and hidden categories like Category:People by name fit into the topical tree without any problem. It's also logical that the "taken with" categories are associated with the cameras they refer to. My example of the Gravity escapement image was not to demonstrate miscategorization but to suggest that the category system varies in how categories are related to their subcategories. --ghouston (talk) 13:05, 29 June 2015 (UTC)

I don't know anything about User:OgreBot/gallery. Perhaps there is some way (or should be some way) of excluding particular subcategories. I don't think you'd want anything in Category:Leica included. --ghouston (talk) 13:10, 29 June 2015 (UTC)

Note: Commons:Categories#Major categories mentions Category:Image sources as a root category, which is wrong: it's a sub-category of the root categories Category:Media types and Category:Media by source. I'll change Commons:Categories#Major categories to reflect reality (put Category:Media by source in the place of Category:Image sources). Doesn't have to do anything with this discussion, just noting it here to avoid confusion. --El Grafo (talk) 13:33, 29 June 2015 (UTC)

(Edit conflict) User:Ghouston, the technical source of the named images is the camera, what else?
It doesn't make sense of dealing with the symptoms if the cause isn't removed.
Sure I want the Leica-Category and her content in this category, it's a company based in Wetzlar with a rich history including all the cameras that are produced here, but not the images of the cameras, because they are from elsewhere... Regards, --Emha (talk) 13:45, 29 June 2015 (UTC)

But then what about similar things like Category:Photographs by lens or Category:Photographs by film? "source" doesn't really make sense there and it doesn't really fit the description at Commons:Categories. If anything, I'd rather have a new root category for stuff like that. --El Grafo (talk) 13:52, 29 June 2015 (UTC)

The cause is varying relationships between categories and their subcategories, so that the relationship of a category with its grandparent etc., categories is unclear. A big part of it in this case is caused by putting the whole Leica company under Wetzlar. The relationship is "based in", I suppose meaning that its head office is located there. However Leica now makes at least some of its cameras in China [2] and it has shops and offices in other countries [3]. --ghouston (talk) 22:49, 29 June 2015 (UTC)

Yes, there are several root categories or entry points. But I don't think it's possible to separate them entirely. Simple example: Category:Photographs is in the root categories

Category:Media types through Category:Images
Category:Topics through Category:Photography and Category:Art media

--El Grafo (talk) 13:49, 29 June 2015 (UTC)

Yes, it is a problem with understanding our category system, but it is not me who misunderstands the categories. We use categories in a hierarchical tree. We don't use tags! That's actually all you need to understand about our categories and why this is a problem. --h-stt !? 12:30, 1 July 2015 (UTC)

@H-stt: I don't know what exactly it is, but the category system at Commons is certainly not a tree, as sub-categories can have multiple parent categories and it contains loops that (indirectly) make categories their own sub-categories. Commons:Categories calls it a en:Directed acyclic graph, but in reality even that is more like wishful thinking because of all the loops … --El Grafo (talk) 13:19, 1 July 2015 (UTC)

What is deeply troubling here is these two things:

that we have an admin who not only doesn’t understand the underlying approach of our categorization scheme, but also comes to the Village Pump making a spectacle of it and demanding a “solution”, and
that we have another admin who comes to the Village Pump to promote what would amount to vandalism were it perpetrated by an IP user («the appropriate solution is to delete each and every "taken with"-cat»).

-- Tuválkin ✉ ✇ 19:26, 29 June 2015 (UTC)

Tuvalkin: This is not the Administrators' noticeboard and not an admin-relevant cause. This is the village pump and I am not talking as an admin, but as a normal user like you.
I would be pleased if it would be possible to you not arguing personally but along the facts. And yes, I have a problem with the situation and would be glad if we could find a solution for this. If all the other users would have told me, that this is only my problem, that's okay for me, too. But as you can read, that's not the case. Regards, --Emha (talk) 09:37, 30 June 2015 (UTC)

Well, if we are looking for a solution for your gallery problem, it seems that User:OgreBot/gallery does have a facility for excluding subcategories. If you don't want to exclude Category:Leica, at least exclude Category:Leica cameras. --ghouston (talk) 23:37, 30 June 2015 (UTC)

User:Ghouston, thanks, but I know how to cure the symptoms but that's not the only concerned case and that doesn't heal the problem in principle. --Emha (talk) 08:10, 2 July 2015 (UTC)

@User:Emha: Categorization system of wiki projects is (since its beginning) designed as multifactorial, comprising many types of categorization relations to one interconnected modular complex. The main your problem is not the categorization system nor specific categories about cameras but your baseless assumptions about the system. The categorization tree here can be never supposed as a simple hyponymic hierarchy, nor a simple meronymic hierarchy. If we would extract pure hyponymic or pure meronymic threads from the categorization structure, wee need to mark a type of relation to every one category relation and filter such threads using these additional marks. --ŠJů (talk) 13:31, 1 July 2015 (UTC)

User talk:ŠJů: baseless assumptions? I read on Commons:Categories: The main principles are: Hierarchic principle.. And a ship in Taiwan is not situated in the city of Wetzlar. It's that simple. If you don't agree to this you have to discuss about changing this official policy of Commons. --Emha (talk) 08:10, 2 July 2015 (UTC)

Multi-hierarchic principle. Not only simple location hierarchy principle. The hierarchy is compound and incorporates many other kinds of relations than only current location. Categorization at wiki projects was allways multifactorial and allways supposed to combine more and very different types of relations. If it uses also relations as "originate from", "registered in", "produced by/in" etc., then, logically, we cannot suppose that every categorization thread will correspond with immediate spatial meronymy. If you don't agree to this you have to discuss about changing the basic principles of all Wikimedia wiki projects, or rather to create your own project which would be not based on them. There exist two ways to comply with your assumptions: to choose a simple-criterion system instead of the current all-embracing complex categorization, or to make the current system more sophisticated (using a thread filter by kind of relation). However, if you want to propose an alternative system, you should well understand the current system at first. --ŠJů (talk) 14:14, 2 July 2015 (UTC)

Electronics Categories

This problem is happening a lot with consumer electronics images, something should be done about this problem. From the friendly, Doorknob 747 (talk) 21:57, 5 July 2015 (UTC) :D

Computer Categories

Same problem is happening, a simple computer model will lead u to the country where the computer manufacture headquarters are located in the categories. From the friendly, Doorknob 747 (talk) 21:57, 5 July 2015 (UTC) :D

Scanner Categories

Laying aside the obvious matter that not all category relations are is-a relations, I still have a problem with some of this "taken with" stuff. For example, https://commons.wikimedia.org/w/index.php?title=File:Mr._Bouatier_working_on_meter,_1954.jpg&curid=30755448&diff=164488000&oldid=149609367, as discussed in part at User_talk:BotAdventures#Scanner.... It seems pretty silly to say that a 1954 photo was "taken with" an Epson scanner. - Jmabel ! talk 19:49, 29 June 2015 (UTC)

Well, that should obviously be something like Photographs digitized with … and separate from photographs taken using a scanner as a camera … --El Grafo (talk) 19:57, 29 June 2015 (UTC)

You can digitize books, digitize photos, and image/digitize 3D objects with either a camera or a scanner. I'm not sure that creating separate categories for all these possibilities for every type of device is a good idea. I think there should be device categories (which will later be converted to Wikidata-like properties if Structured data ever happens) which can be assigned automatically from Exif in many cases. A single file can potentially have more than one device, e.g., the original camera, the scanner, or software that processes it (e.g., for enhancements or processing raw camera images), although sometimes only one can found in Exif. Any other information, e.g., that it's a book digitization, or a photo of a 3D object made by a scanner, can be added separately instead of creating intersections with the device type. --ghouston (talk) 23:02, 29 June 2015 (UTC)

eBay upload script wanted

From time to time, I find out-of-copyright images, such as old postcards, on eBay. There's one above. It would be handy to have a tool or script that will do the upload, capturing the appropriate metadata, like we have for Flickr. Does anyone know of one? Andy Mabbett (talk) 12:51, 30 June 2015 (UTC)

Not as far as I know. eBay has their own API, however as users can upload many photographs of objects, auction entries may be for multiple items and most sections of the auction page can be used in varied custom fashions by the seller, I think useful automation is a bit of a nightmare. Were I designing a tool, I would provide a webform, harvest details and then let the user fill in the blanks or correct details (like selecting which image is the relevant one to upload from a drop-list). All in all, it's a weak scenario compared to Flickr, where the API is explicitly returning fields about an image you want to upload, not information about what it may represent, tangential events, or as part of a group object.

P.S. Flickr upload tools are a bit of a hazard for mass uploads, however I'm reading your request as a tool for item by item uploads, not mass uploads. --Fæ (talk) 13:06, 30 June 2015 (UTC)

Yes; item by item. A pre-filled form would be fine - anything that removes a step or two from the drudgery. Andy Mabbett (talk) 13:54, 30 June 2015 (UTC)

@Fæ: Idea: would you consider automatically submitting the eBay page to one of the web citation websites when your form is used? Eventually, the eBay link goes away and sometimes the licensing is questionable without being able to see it. Example: if a postcard is uploaded with the claim that it was published pre-1978 with no copyright notice and all we have is the front of the postcard, it's difficult to know that the license is valid because we can't see the back to verify that there is no copyright notice on there. But if the eBay link was preserved, then we could see the other side of the postcard and verify that there was no notice ... or we could see that the seller never provided a copy of the other side of the postcard, in which case it should be nominated for deletion. --B (talk) 15:24, 1 July 2015 (UTC)

Yes, auto-archiving the page would be possible, within whatever usage limits there are for the service. It may mean a bit more cookie-fiddling and a wrapped-in or popped-up human-check or similar jiggery pokery.

Sorry if my text above might be misleading, but I do not have the volunteer time to do this as a project, my real life commitments are likely to be a bit overwhelming for several more months (believe me, I would *much* rather be playing code monkey than handle the depressing stuff I'm going through). Anyway, though I can do this sort of API experiment, I'm actually rather hacky/bad and slow at it, and I have a big guilty secret backlog of projects I ought to return to and finish off. My description above was how I would initially think about it, with the hope that someone faster and smarter would have a crack at it.

--Fæ (talk) 15:34, 1 July 2015 (UTC)

User:We hope has a personal method of uploading a preliminary image which shows evidence for lack of a copyright statement, then overwriting it with another image with only shows the area of real interest... AnonMoos (talk) 22:22, 5 July 2015 (UTC)

Upload large files?

If I try to upload a large file (Video, 700MB) I get Server-Error "413 Request Entity Too Large". --Slick (talk) 11:45, 11 July 2015 (UTC)

I believe the max upload size using a single chunk is 100MB ^{[citation needed]}. The size of 1000MB you see on Special:Upload is the max file size allowed by MediaWiki itself (regardless of how many chunks), since HHVM is unable to determine the max request size. Try chunked uploading instead. --Zhuyifei1999 (talk) 12:15, 11 July 2015 (UTC)

This section was archived on a request by: Slick (talk) 07:59, 12 July 2015 (UTC)

TIFF from LoC

Hi, On every file available from the Library of Congress, there are a 8-bit and a 16-bit TIFF files (e.g. [4]). I usually upload the TIFF (by URL) before uploading a JPEG version because downloading from WM servers is much faster (x10) than from LoC servers. ;o) The TIFF much be converted to JPEG (8-bit), so is there any interest to upload the 16-bit TIFF file? I do the conversion with Gimp, which only handles 8-bit. The 16-bit file is always available on LoC. So? Regards, Yann (talk) 12:53, 3 July 2015 (UTC)

How about just uploading tiffs? --Jarekt (talk) 14:12, 3 July 2015 (UTC)

@Jarekt: You mean not uploading JPEG? Or uploading both 8-bit and 16-bit files? Also noteworthy is that the TIFF files are Adobe RGB. So I convert them to sRGB before uploading JPEG here. Regards, Yann (talk) 14:23, 3 July 2015 (UTC)

I've actually recently come across another similar with LoC images.... from bulk uploads by Fae (not that I am faulting him, at all)... Photochrom images that were available from the Library of Congress Prints and Photographs Division directly in full-resolution as TIFF and JPEG, but also available (and uploaded separately) as lower resolution PNGs from the World Digital Library (which is a project run by the LoC). I'm tempted to nominated the lower res PNGs as duplicates, except that they are from a different 'exact' source, and not the same format. Examples:

File:Mosque of Abder-Rhaman, Algiers, Algeria-LCCN2001697807.tif (8.32 Megapixel TIFF)
File:Mosque of Abder-Rhaman, Algiers, Algeria-LCCN2001697807.jpg (8.32 Megapixel JPEG)
File:Mosque of Abder-Rahman, Algiers, Algeria WDL2450.png (1.41 Megapixel PNG)

As you can see, the World Digital Library PNG is far lower res. Revent (talk) 03:18, 5 July 2015 (UTC)

I'd say upload 16-bit if there is any useful information that would be lost by conversion to 8-bit, which would usually be the case. (Images with a substantial amount of noise wouldn't benefit from 16-bit. Most other scanned images would, notably anything with a compressed dynamic range, 16-bit HDR.) Anyone downloading the tiff is looking for maximum quality, while a JPEG should be "ready to print" or "ready to display" with full contrast and no HDR information. SilverbackNet^talk 07:58, 5 July 2015 (UTC)

As I said above, the bigger TIFF is always available on LoC. The question is: "is there any use for it on Commons?" Yann (talk) 13:47, 6 July 2015 (UTC)

We don't know that it will always be available on the LoC. One scholar working on the Manhattan Project was complaining about scores of publicly available documents whose websites disappeared or stopped working, or in one case were corrupted by an ill-advised line-feed conversion. Not intentional, but there wasn't the budget and/or will to fix it. Maybe the LoC as library will be better, but one change and they could be made inaccessible indefinitely.--Prosfilaes (talk) 19:27, 6 July 2015 (UTC)

User talk protection

Are protections like that allowed? It looks like kinda disrespect to common communication practices from my point of view. --Base (talk) 17:03, 4 July 2015 (UTC)

I can understand, but semi-protection should be sufficient. Also a link to COM:AN would be useful. @Jameslwoodward: Jim? Regards, Yann (talk) 17:22, 4 July 2015 (UTC)

@Base, what is so hard to understand with "I will be on vacation, away from the Internet, through the first week in August"? If he hadn't protected his talkpage, then after 3 or 4 postings, the next poster wouldn't notice Jim's "absence message" and might become angry when he gets no answer. --Túrelio (talk) 19:05, 4 July 2015 (UTC)

Well in ukwiki we had a user who won't reply if you forgot to greet him when writing to him. He referred to need of respect but in that way actually disrespected community members who could just forget to say "Hi" because were thinking about other, more important atm stuff. It looks like a case of the same kind in some way. Are you really sure that a poster who doesn't get answer and fails to read the notice (though with some CSS you can do that a block of text sticks to the screen which probably solves the possible problem you mentioned in much better way than protection, IMHO) will be more angry than a would-be-poster who will not be able even post because of the protection? For example, in my case of TP use practice I'd rather write something on TP and get answer in several months because of the addressee vacation rather than I'm stopped from writing now and forget the thing I wanted to say in the months. Well not that I'm a typical case but I'm not too peculiar to neglect. (Just to clarify I didn't have anything to write the user now, just saw the action in WL and it drew my attention.) --Base (talk) 21:15, 4 July 2015 (UTC)

Jim should be aware that he won't get deletion notifications. -- Rillke^(q?) 19:20, 4 July 2015 (UTC)

@Base: The answer is unambiguously no, Jim went against Commons:Protection policy which limits page protection of this type to "vandalism and edit wars". --Fæ (talk) 19:45, 4 July 2015 (UTC)

Túrelio has my reason exactly -- in the past I have been away for much shorter periods and have had angry messages because I did not respond. Of course an experienced user would look at my contributions and see that I had not been on Commons since before he left the message, but novices just get mad. Therefore, I thought that it would be better to prevent novices from leaving messages.

However, I'll be perfectly happy with whatever Yann and Turelio decide. BTW, Rillke, I am well aware that I won't get deletion notifications, but I've never had one and I think I can safely say that my present 500 or 600 uploads are all safe from valid DRs. And now, I really am gone until August. . Jim . . . . (Jameslwoodward) (talk to me) 23:21, 4 July 2015 (UTC)

Talk page protection is unnecessary as many people including me watching his page. If something unexpected happens, we can manage it (like replying to an angry novice). I think Yann or Túrelio can unprotect it now. J e e 03:33, 5 July 2015 (UTC)

I changed it to semi-protection. Regards, Yann (talk) 11:27, 6 July 2015 (UTC)

July 05

Is there any policy against pages with a large number of images displayed?

I'm just curious if there is any type of policy against pages that display a large number of images? I was looking at the "What links here" page for some of my uploads and came across pages similar to the "[[User:Josve05a/Possible DRs/2015 May]]" page. This page displays 2974 thumbnail images on the same page. This IMO is a waste of server-side and client-side resources. Offnfopt^(talk) 06:31, 6 July 2015 (UTC)

There are a lot of such pages, and even some uploading software - as Commonist and Vicuna -routinely create user galleries, and as far as I know no problem has even arisen except for loading time. Dividing such pages into smaller pages wouldn't spare server resources. Probably making smaller galleries is a good practice, but not a mandatory rule to be enforced.--Pere prlpz (talk) 12:18, 6 July 2015 (UTC)

It's not a waste of client-side resources unless people are viewing them, at which the question might involved the client-side resources involved in splitting them up and having to deal with many pages instead of one. It's not a waste of server-side resources again unless they're being loaded, in which case, 2974 thumbnail loads is probably a drop in the bucket in the world of Wikimedia. It's all false optimization.--Prosfilaes (talk) 19:31, 6 July 2015 (UTC)

Parsing pages with that many thumbnails takes a while (So, there might be some latency on rendering the page). Thus I wouldn't recommend doing that for any page meant to be regularly viewed, as it will be slow to load for the user. Beyond that I wouldn't worry. Bawolff (talk) 01:24, 7 July 2015 (UTC)

I agree with User:Bawolff, it realm is not something that one should worry about. On, any Wiki there are pages with thousands of images. Also, if one does a search, they will see many images in one page, thus indicating that there is no need to set a limo to how many images can a specific page can have. Doing such a limit may have actually some adverse affects to the efficiency of this site even. From, the very friendly Doorknob 747 (talk) 05:26, 7 July 2015 (UTC) :D

Request for uploading a Flickr stream

Hi all, this is Scott (Russavia). After my request the African Union Mission to Somalia has kindly relicenced their Flickr photos from (C) ARR to CC-0! I have already uploaded one photo (and using externally for an educational purpose) and it can be found in Category:Photographs by the African Union Mission to Somalia. Would someone out there like to get a bot to do the rest of the stream? Heaps of valuable Somalian photos to be found. Once done, I'd recommend dropping a note over on Somalian Wikipedia and letting them now they are available. The Flickr stream is found at https://www.flickr.com/photos/au_unistphotostream. Cheers, 37.221.160.114 07:23, 6 July 2015 (UTC)

Doing… --Zhuyifei1999 (talk) 08:17, 6 July 2015 (UTC)

Thanks Zhuyifei1999 for helping with this. 6,000+ photos from Somalia will be an awesome addition to Commons. I'll try to get some Somalian editors to help with categorising, etc. And hopefully they will find great use for them. Cheer, 37.221.160.114 11:07, 6 July 2015 (UTC)

World satellite map with political borders

Hi all. I am looking for a similar map to this one but also showing country borders. Is anyone aware that it exists in Commons? Thank you very much. Sentausa (talk) 08:54, 6 July 2015 (UTC)

File:Worldglobe.jpg, or file:Robinson world.png. Sincerely, Taketa (talk) 09:00, 6 July 2015 (UTC)

I saw File:Worldglobe.jpg before, but File:Whole world - land and oceans 12000.jpg looks much nicer to me. And unfortunately, file:Robinson world.png doesn't show the country names. So, apparently we don't have a version of File:Whole world - land and oceans 12000.jpg which shows the country borders, right? I wonder if I can ask for it be created in Commons? Thanks! Sentausa (talk) 13:01, 6 July 2015 (UTC)

Cross post - can a sculptor CC license a photo of a traditionally copyrighted artwork?

I am seeking more opinions at Commons:Village_pump/Copyright#Sculptor_wishes_to_donated_images_of_copyrighted_sculpture. Blue Rasberry (talk) 14:44, 6 July 2015 (UTC)

cat redirect question (Category:Memorials)

Category:Memorials currently redirects to Category:Monuments and memorials in unidentified countries. I understand the choice -- it means that if someone adds the superseded Category:Memorials, things will be recategorized by a bot into a place appropriate to future work -- but it seems a bit bizarre. After all, it will put that "unidentified countries" category on something where the category may be perfectly well identified by another category or by the description. Shouldn't this just redirect to Category:Monuments and memorials? - Jmabel ! talk 18:51, 6 July 2015 (UTC)

I agree with your assessment. Sure, stuff shouldn't be put directly into Category:Memorials, but that is easy to fix. The redirect is just weird. --Sebari (talk) 19:36, 6 July 2015 (UTC)

Yes, if you type "Memorials" into the search box, you get this redirect. I suggest reverting the last edit by User:Butko. --ghouston (talk) 23:12, 6 July 2015 (UTC)

It actually is not right even, its like saying why even give a name to a memorial, if people are only going to call it a memorial. Even the 9/11 memorial is redirecting to memorial. From, the very friendly Doorknob 747 (talk) 05:29, 7 July 2015 (UTC) :D

OK, changed to redirect to Category:Monuments and memorials. - Jmabel ! talk 05:47, 7 July 2015 (UTC)

Problem with UTC time gadget.

I feel the UTC-Time gadget is sending some users 4 hours back in time, according to the gadget. It can bee seen in this screen shot image I took, and compare it with the UTC time of the most recent edit with the time of the gadget in the top right corner of the page.

But, aside from the send back in time joke, can someone fix this problem please. Thank you in advance. From the very friendly, Doorknob 747 (talk) 22:16, 5 July 2015 (UTC) :D

It's just a bit of JavaScript[5] that gets the current time from your own computer. It's working for me (currently 23:18:48). I guess you already checked that the time on your computer is right. --ghouston (talk) 23:18, 5 July 2015 (UTC)

What is your local time offset from UTC by the way? Is it related at all to the 4 hours? --ghouston (talk) 23:19, 5 July 2015 (UTC)

Then they should not even name it a UTC-Time gadget and call it a local time gadget. It can confuse someone. Also, another thing about this gadget, is that, there should be a option for 24-hour or a 12-hour mode. From, the very friendly Doorknob 747 (talk) 05:37, 7 July 2015 (UTC) :D

It's called UTC-Time because it displays the time in UTC. However it assumes that JavaScript that calls the API for UTC time on your computer will get the right value. If you set your own computer to the wrong time, or maybe set it to display the right local time but with the wrong timezone, it will give the wrong answer. --ghouston (talk) 11:38, 7 July 2015 (UTC)

July 06

Ambulance etc. categories

At the moment the categories concerning ambulances and other medical emergency vehicles are kind of a mess. This is mainly due to differing systems around the world, but also due to unclear terms. Therefore I would like to develop a meaningful, sensible structure with consistent names for those kinds of vehicles. Here is a first stab at it for discussion, mainly from a German perspective:

Emergency medical service vehicles - base cat
- ~~further special cats, for example for media types, models, in special situations or whatever comes up~~

Any comments, especially perspectives from other countries? -- Sebari (talk) 14:18, 7 July 2015 (UTC)

The current categorization is relatively clear and logical, i can see no extra mess there. The fact that the "basic", "default", "prototypical" kind of ambulance vehicles, i.e. ambulance automobiles (vans), have not its special subcategory, is a usual phenomenon which have its reasons (similarly, "electric trams" are considered as the default kind of tram, but horse-, steam-, gas- or flywheel- or treadle-powered trams are categorized under trams). However, special subcategories for "Ambulance automobiles" can be created if needed.

To reserve the name "Ambulances" ONLY for ambulance automobiles and exclude other ambulance vehicles from it is not a good idea. Such a solution would cause a big mess and inconsistency in the categorization. Generally, ambulance automobiles are no more and no less ambulatory than ambulance boats, buses, motorcycles, Segways, helicopters etc.

To separate emergency vehicles by more detailed purpose (only transport of medics, only transport of patients, only a mobile first aid workplace, and all 4 possible combinations of them, i.e. 7 possibilities) would be complicated, and not reliably specifiable in some cases. IMHO categorization by kind of vehicle and by operator+country should stay preferred. More detailed categorization can be added but should not disrupt the current system.

As regards a perspective from my Czech country and my language, we use the word "ambulance" primarily for "outpatient(s') department", i.e. an office of non-hospital physician, or an outpatient service in the hospital. Ambulance cars are called "sanitní vůz" or "sanitka", literally "sanitary vehicles", from Latine "sanitas" = health, borrowed through French and German languages. However, the word "ambulance" is used as an "international" word also for emergency vehicles. --ŠJů (talk) 16:18, 7 July 2015 (UTC)

If you look into country-specific categories, you will notice the mess, since names like "Rapid response vehicle" are used for completely different purposes. Sometimes is a super-cat for all kinds of emergency vehicles, sometimes it is a sub-cat for a specialized kind of vehicle. Or categories are not very clear. In my opinion, differentiating between different ambulance types makes a lot of sense. In Germany there is a clear distinction between RTWs, NAWs, KTWs, FRs, and NEFs, for example, and they are categorized as such. Similar distinctions exist in other countries, and a common hierarchy tree would be useful. I don't care particularly how the cats are named, though. I was just using Ambulance here, since it fits the definition as used on en Wikipedia: An ambulance is a vehicle for transportation of sick or injured people to, from or between places of treatment for an illness or injury, ... --Sebari (talk) 16:27, 7 July 2015 (UTC)

@ŠJů: You say 'we use the word "ambulance" primarily for "outpatient(s') department"', but don't say what the actual word is in Czech. Is it really a cognate of "ambulance", not "ambulatory" (etymologically "capable of walking"), a word that also has that exact meaning in English? - Jmabel ! talk 16:45, 7 July 2015 (UTC)

@Jmabel: As I know, the word "ambulance" was used for field hospitals originally. Afterwards, the meaning was transferred to various civil medical "terrain services". I was asked about "perspectives from other countries", and I answered to it. However, I'm not sure that the meaning of the word in English is so exact as you claim. As I can read in the enwiki article, the term cover various kinds of vehicles and varous their purposes, some of them are closer to the prototypical core of the meaning, some of them are peripheral or specific. That's the main problem of the proposal above.

@Srittau: Regrettably, the most definite aspect of your proposal was to exclude ambulance boats, bikes, buses and helicopters from the current category "Ambulances" - so actually, to narrow its meaning to ambulance automobiles only, and to cover its current meaning with a new category Emergency medical service vehicles. Such a change is very controversial and maybe illogical and counterproductive.

If you have some other specific proposal, it should be clear and well-founded.

As I can see, you propose to replace the current name "Rapid response vehicles" with your name "First responder vehicles". You can open a discussion at the discussion page of that category by a {{Move}} proposal, invite its creator and users to it, and bring some convincing arguments for the proposal. Why you consider your term as more worldwide universal, more unambiguous, more correct, more understandable etc. If you mean that some of the country subcategories deviates from the scope of the root category, you can correct it (move the wrong categorized files) or open a discussion with the users who filled that specific category.

If you will have some other specific and well-founded proposal or idea (e.g. to create a subcategory thread of Mobile intensive care units, you can implement (or discuss) it without disruption or question of the current basic structure. As regards etymological anchoring of the word "ambulance", IMHO it can cover all three purposes of these vehicles as mentioned above, and the 3 purposes can be variously combined. E.g. every emergency ambulance should be able to be used as a mobile intensive care unit, but not all intensive care units are intended to transport patients. Non-emergency transport vehicles can fall under the term "ambulances" also. The text of the enwiki article is a bit longer than your qutotation. Moreover, there exist special emergency vehicles for transport of blood, transplants etc. --ŠJů (talk) 17:47, 7 July 2015 (UTC)

As I said above, I don't care about the exact names for now. The problem is that "Rapid response vehicles" as currently used is not the same as "First responder vehicles". Sometimes it is used as such, sometimes it isn't. And that is the core problem we have at the moment: no consistent naming and no documentation of said naming. So, in a first step, let's step back from names and just consider the following structure:

Base cat for ambulance or whatever vehicles
- By country cats
  - ...
- By type cats
  - Cat for about van-sized road vehicles designed to transport patients (in Germany those would be further divided into KTWs, RTWs, and NAWs)
    - cats for special types of those vehicles
  - Cat for vehicles that transport Certified First Responders and similar personell
  - Cat for vehicles that transport emergency physicians to an emergency, but not fitted to transport patients
  - Helicopters (yay!)
    - possibly sub-divided
  - Buses
  - Boats
  - Bikes
  - ...
- further special cats, for example for media types, models, in special situations or whatever comes up

Let's work on that structure first, then agree on names. --Sebari (talk) 18:11, 7 July 2015 (UTC)

You mix two criteria together in the "by type" section. Type of vehicle is one thing, purpose of vehicle is a different thing. By type of vehicle we can distinguish road and terrain vehicles (automobiles, vans, trucks, buses, motorcycles, bikes, Segways, snowmobiles, snowcats...), aircraft (at first helicopters) and watercraft (boats).

As regards "by purpose" (by function) criterion, we can distinguish (and combine) emergency/non-emergency transport of medics, emergency/non-emergency transport of patients, emergency/non-emergency transport of medical equipment and material, and mobile "treatment rooms". However, this sorting partly follows from the categorization by type of vehicle. Cars, motorcycles or bicycles are mostly intended for transport of the medic. Van-sized road vehicles are mostly multi-purpose, usable for all these purposes. The purpose can also follow from the operator: emergency service have emergency vehicles only, hospitals can operate non-emergency transport vehicles etc.

The categorization structure exists already. If you want to improve it, you should bring specific and considered proposals of specific and needed changes - to rename or merge a category, to create a new subcategory, to change categorization of an existing category etc. We not build the categorization on a greenfield site. --ŠJů (talk) 20:48, 7 July 2015 (UTC)

The structure does not exist or at least I can not see it. As pointed out several times now, naming throughout the cat tree is not consistent. The same term is used for different things. If you disagree, please go ahead and add meaningful descriptions to the existing categories, so we know what they mean. For example, what exactly is a Rapid response vehicle? Above you claimed it is the same as a first responder vehicle. But if you take a look at the category you will see that it is contains lots of sub-cats that do not fit my description above. So, what is it then? We have at least a documentation problem, which caused a messed structure. Therefore I see no other approach than to take a step back and work out a sensible categorization. And then look at our categorization and fix it. Just closing your eyes and claiming there is no problem does not help. --Sebari (talk) 22:11, 7 July 2015 (UTC)

Yes, there was really a problem with Rapid response vehicle - its categorization didn't correspond to their interwikis and it contained several improperly categorized subcategories. Most of these mistakes were made by Pierpao in 2011. However, the interwikis provide clear definition, and all "true" subcategories (by country) of that category were categorized and used properly and consistently. The problem was not a "non-existing structure" but only several mistakes in one category. I fixed them. Maybe, the category can be renamed to some more clear and unambiguous of the synonymic terms, but it is also a specific particular problem only.

As regards your proposal to distinguish cars of Certified First Responders from cars of other emergency physicians, you can try to do it, but you should anticipate that most of users and photographs are not able to distinguish them reliably. I even don't know which is relation between Certified First Responder and Ambulance emergency response vehicle, though I checked the articles. --ŠJů (talk) 00:39, 8 July 2015 (UTC)

Tool for changing the descriptions of multiple images

Hello, is there by any chance a tool, similar to cat-a-lot, with which I can change the description of multiple images at once? That would be very helpful for Wiki Loves Earth, because sometimes there are 10 different images from the same place. Thanks in advance, --Лорд Бъмбъри (talk) 17:09, 30 June 2015 (UTC).

You could possibly use COM:VFC for the purpose, if you are simply replacing one block to text with another. Revent (talk) 19:12, 30 June 2015 (UTC)

@Revent: How can your utc time stamp for June 30, be 19 hour, when my UTC Wikmedia gadget displays 18 hour still. where did the hour go? Did I go back in time. Places check mark on discoveries to make "go back in time. Check". Doorknob 747 (talk) 22:23, 30 June 2015 (UTC) :D

@Doorknob747: It's a mystery, lol. My timestamp (just checked it) matches both the UTC time gadget, and a quick check against a network time server. Revent (talk) 03:10, 1 July 2015 (UTC)

@Revent: Sure is a mystery, now its 4 hours behind, that is after 5 days, its like as if the clock is slowing down, in the gadget on the top right corner of the page. Should I upload a screen shot image of the problem and add it on this page for people to see the problem? From the friendly, Doorknob 747 (talk) 21:51, 5 July 2015 (UTC) :D

@Doorknob747: I don'y know exactly how that gadget works, but I would assume it's based on local javascript... try clearing cache and see if that fixes it. Revent (talk) 22:30, 5 July 2015 (UTC)

All the hard work seems to have been done, but could we have a version that removes all the scary stuff about deletion. There is often much work to be done in the {{Information}} tag, other than date, source and permission. I am particularly interested in the description= field. For example, in an upload from a museum, all images are often labelled Item in Hogwarts Museum. Running through this, image by image, I could identify each item in my speciality, making the image usable in future articles. Similarly, If we are talking about one museum I could add to all images a geotag. These are late night tasks done when the brain has turned off. A Batch rename may be more complex to do- but the ability to rename a group of images to something more specific, or correct a title error would be useful. But even the simple facility to add a English translation of a foreign language description would be useful. I suppose the answer is to download the .js file and tweak it- but that is also very scary! --ClemRutter (talk) 18:30, 8 July 2015 (UTC)

SVGs as PNGs

Is it just me, or has the option for rendering SVG images as PNGs disappeared? On SVG file pages, there used to be a line of text saying something like "this image as a PNG", and then links to PNGs of varying sizes. But now I can't seem to find this. Zacwill16 (talk) 12:52, 6 July 2015 (UTC)

It's just you. On the description page for (e.g.) File:Bulletin Board with notes.svg the line says "Size of this preview: 800 × 568 pixels. Other resolutions: 320 × 227 pixels | 640 × 454 pixels | 1,024 × 727 pixels | 1,280 × 908 pixels." All links point to PNGs. --Magnus (talk) 12:59, 6 July 2015 (UTC)

That's not what I was talking about. Below that, there were options for 200px, 500px, 1000px and 2000px. Zacwill16 (talk) 13:25, 6 July 2015 (UTC)

Those were added by JS, not mediawiki. Maybe somebody disabled the gadget. Bawolff (talk) 01:21, 7 July 2015 (UTC)

Yes and no, this was (not a gadget) fully in the Common.js and was simply removed as deprecated because of redundant. ↔ User: Perhelion (Commons: = crap?) 01:33, 7 July 2015 (UTC)

I would like an entry box in the image description page so you can enter the desired width and then the new PNG is rendered in the new tab. This is easier than copying and pasting the PNG link to a new tab and then change the width value in the URL. Ideally there should be a PNG link with the same dimension as the SVG source. -- Sameboat - 同舟 (talk · contri.) 01:54, 7 July 2015 (UTC)

How was it redundant? I found it useful and convenient. Zacwill16 (talk) 09:34, 7 July 2015 (UTC)

@Zacwill16 as sayed above, there is already a line with the same function but other resolutions. So your "useful and convenient" are the different resolutions 200, 500, 1000, 2000? If yes I agree Sameboat to implement an input field for an variable size!? Open a Phab task or made an new Common.js hack for this? ↔ User: Perhelion (Commons: = crap?) 11:38, 7 July 2015 (UTC)

Yes, those resolutions are larger and more workable. Zacwill16 (talk) 12:10, 7 July 2015 (UTC)

I don't think the currently available widths in the line of "other resolutions" suffice unless either one happens to be the size of your screen. Also Gnome/librsvg is slightly inaccurate in rendering SVG text when the resultant PNG resolution isn't identical to the "nominal" dimension of the SVG source or multiplied by integer. Still it's something can be easily overcome without introducing new JS, if you know how it works, but I think most editors don't. -- Sameboat - 同舟 (talk · contri.) 15:09, 7 July 2015 (UTC)

When did we stop being able to manipulate a url ? Do we really need buttons for everything ? —TheDJ (talk • contribs) 20:04, 7 July 2015 (UTC)

BTW, you can always discuss, find new defaults that will work for all users (not just SVGs on Commons) and file a ticket with a request to consider adapting the current defaults. But the gadget is no longer needed for sure, and having it adds unnecessary lines in the page, flashes in the rendering, code and maintenance burden. —TheDJ (talk • contribs) 20:21, 7 July 2015 (UTC)

Is it reasonable then to ask at Commons:Village pump/Proposals for higher resolution entries in this list (preferably up to a size that can be used to judge FPs and offers reasonable detail, around 6MP)? — Julian H.^✈ 20:56, 7 July 2015 (UTC)

These additional options were added by MediaWiki:Common.js - @TheDJ: Not everyone likes working with URLs, especially if they are not straightforward like http://commonsupload.com/w_50px/image_name.ext - I agree they were mostly redundant and if other options (larger ones) are required, this should be discussed on the village pump. Perhaps MediaWiki could be more awesome in general; instead of providing these links, it could be a dropdown like MediaViewer (but including a free-form input option) for viewing and downloading. -- Rillke^(q?) 21:38, 7 July 2015 (UTC)

Info (EC) On en.wikipedia, the script at en:MediaWiki:Common.js/file.js was deleted, whereas in de.wikipedia it's still contained in de:MediaWiki:Common.js (and working). Here on Commons, the script was removed from MediaWiki:Common.js by Steinsplitter without a detailled explanation. --Leyo 21:46, 7 July 2015 (UTC)

Reverted the removal for now, see MediaWiki talk:Common.js#function SVGThumbs() redundant. --Leyo 21:52, 7 July 2015 (UTC)

I provided a valid reason. Deprecated - yes, if a function is aviable in mw the unneeded js hack can be removed without discussion. However, i haven't noticed that the new mwfeature is 100% similar to the js hack. Sorry for that. --Steinsplitter (talk) 09:25, 8 July 2015 (UTC)

Policy clarification needed for images with OTRS pending but no license

Large fraction of images uploaded without any license use {{OTRS Pending}} instead. See for example here or here. For years I have been tagging such files with {{No license}} under assumption that COM:LIC requires all files to have a license template and uploaders should not be uploading new files unless they know under what license files are released, since the release might not be under license allowed on Commons. Unfortunately the COM:LIC policy does not mention OTRS, and COM:OTRS is more like guidelines instead of policy and it also does not deal with issue of WHEN is the license needed. Over the years I had a lot of discussions with confused uploaders, some new and some very experienced admins from other projects who were advising for years that license can be added after OTRS permission is processed. Lately User:JuTa was removing {{No license}} tags like here leading to this discussion. For me that is a sign that we do need clarifications to our current policies so we all follow the same rule book. As I see it our options are:

Tag all images without a license with {{No license}}, even the ones that claim {{OTRS Pending}}. Such files will be often deleted after 7 days.
Leave files alone and after 30 days {{OTRS Pending}} will begin displaying {{No permission since}} which will lead to deletion after additional 7 days. This option would cause files to remain without license for 37 days before it is deleted.
Create some new processing pathway

--Jarekt (talk) 14:25, 6 July 2015 (UTC)

From a Commons policy perspective, and based on pragmatic experience as a OTRS volunteer and Commons contributor, I believe that Commons should adopt processes that disregard off-wiki correspondence about the possible copyright status of a file, until the point when a specific statement has been verified. Waiting for over a month for what may be damaging copyright violations to be removed, especially photographs of people or the recently deceased, is unacceptable. The OTRS pending template can be added by anyone, including those that may deliberately use this as a back-door for the Commons system to get images into high profile Wikipedia articles (noting that Wikipedians should be able to assume that images from Commons are at a more reliable free copyright status that on other projects). If anything we should focus on improving the undeletion work-flow and where there are associated claims of backlogged OTRS correspondence, these are flagged or escalated for attention if the file has been deleted or is about to be deleted.

We must encourage anyone to create reasonable deletion requests even when the OTRS pending template is added, and continue to be prepared to delete files after 7 days. Administrators are supported by policy in acting to speedily delete files where, in their view, copyright claims appear in any way suspect. Procedures should not leave an Administrator unable to act, just because they do not have OTRS access. --Fæ (talk) 14:46, 6 July 2015 (UTC)

I do have a broad OTRS access, and I often search OTRS for records related to files with {{OTRS pending}} but no license before tagging them. In majority of the cases search for the name in the "author" field or search for the filename does not find any hits. As for the undeletion work-flow, many such requests, especially for files originally tagged by me, end up on my talk page and are promptly undeleted. --Jarekt (talk) 15:09, 6 July 2015 (UTC)

Sure it can be quick when all tools are in the same hands, the user is experienced enough to be relied on to apply their judgement and willing to be held to account afterwards. However we want to encourage more users to be active in chasing up possible copyvios, including non-admins who know enough about copyright to act, admins without OTRS access and OTRS volunteers who are not admins. Providing an easy workflow is key to gaining more helpers. Fæ (talk) 15:18, 6 July 2015 (UTC)

Hi, I think we need some common sense in these cases. I check if the claim of a permission is plausible. If yes, then waiting for about one month is fine for me. If it is just a file copied from the web without any real possibility to get a permission, then tagging them with "no license" or "no permission" is fine. Regards, Yann (talk) 19:27, 6 July 2015 (UTC)

But waiting for a month means that we are hosting a file with no license for a whole month before deleting it. I personally do not like it. Many people I interact with in last couple years while I was working with files with no license seem to have very little understanding of the concept of license. I have little confidence that many of them will provide proper OTRS permission form. --Jarekt (talk) 02:14, 7 July 2015 (UTC)

Quick idea for option 3: Instead of the image, display a message like "Coming soon … (This image is currently hidden and will appear once copyright stuff has been sorted out)". Make a simple switch for that, accessible to admins, OTRS members and license reviewers (and let them be able to see the hidden content). Much easier to understand for newbies than deletion and undeletion, while at the same time nothing potentially copyrighted is being displayed. Would probably require a new module for MediaWiki, though … --El Grafo (talk) 09:57, 7 July 2015 (UTC)

+1 for your idea, El Grafo. The question is if we can do this without major coding. One idea that comes to mind is the following: Overwrite the image in question with our new coming soon image, then hiding the original upload. When OTRS checks out, we can easily restore the original. Doesn't work for non-admins, tho. Might be a work-around until we find a better solution via software. Waiting a month for permission is far away from ideal, on the other hand we might kill some enthusiasm of new uploaders if we act too fast. I really like the idea El Grafo came up with. --Hedwig in Washington ^(mail?) 15:12, 7 July 2015 (UTC)

Yeah, might be possible to do it that way. Not sure if admins would like the additional work load, though. But I'm pretty sure implementing this into a new feature would require major coding. --El Grafo (talk) 15:46, 7 July 2015 (UTC)

It doesn't matter if we like it. It just needs to work... Maybe we can use a script? Ping Scriptgurus!

--Hedwig in Washington ^(mail?) 15:58, 7 July 2015 (UTC)

The only place most new users see the image is on a wikipedia page replacing image on wikipedia with "Coming soon" image might not be popular outside of Commons. As for original idea by El Grafo, curently image can be either in deleted or undeleted state, it seems unlikely to me that software developers would create a 3rd limbo state for such a small number of images. --Jarekt (talk) 16:46, 7 July 2015 (UTC)

To be honest, I think every file uploaded by an inexperienced user should by default go into a "to be checked" state and only be publicly displayed after an experienced user has flicked a switch. Probably not gonna happen, though ;-) --El Grafo (talk) 08:04, 8 July 2015 (UTC)

Another idea for option 3 would be writing some new messages more specific to this situation which would be added to the file and uploder's talk page. Part of the confusion is that {{No license}} message is too broad and many users do not understand it. Tools that currently add {{No license}} could be modified to add this new message if {{OTRS pending}} is detected. The new message could be more specific about what is needed and can explain that if image is deleted than it can be easily undeleted once license is provided or OTRS is processed. We can also create a new tracking pipeline (like Category:Media without a license or Category:Media missing permission) for such images that can have a different time limit (maybe 2 weeks?). --Jarekt (talk) 16:46, 7 July 2015 (UTC)

If the file has {{OTRS pending}}, then I think that it is better to leave it alone, and treat it as any other OTRS pending file which is subject to deletion after a month. A file with {{OTRS pending}} with no copyright tag is better than a file with {{OTRS pending}} with a wrong tag, in particular if no permission has been granted. Someone might find the file information page and might mistakenly believe that the incorrect copyright tag applies and run into trouble when trying to use the picture somewhere. It may even be better to change the upload wizard so that no licence is selected at all if {{OTRS pending}} is used. The correct copyright tag can be added by the OTRS member when the ticket is processed.

Concerning copyvios with {{OTRS pending}}, maybe there should be a special dated deletion tag which OTRS members can use if the member has been able to confirm that nothing has been sent to OTRS within a week or so - but it may be more time-efficient to simply ignore the files for a month and hunt down other copyright violations elsewhere. --Stefan4 (talk) 20:22, 7 July 2015 (UTC)

I agree that no license is better than incorrect license. I was not proposing asking people to add incorrect licenses, but to coordinate with the copyright holders BEFORE the upload so the image is uploaded with the license which will be in the Permission. I am actually not very concerned about copyvios with {{OTRS pending}}, since I do not recall running into any. My concern is with images using {{OTRS pending}} instead of a license uploaded by users that never looked as COM:OTRS who will never follow up with actually sending the permission. As long as image is on the Wikipedia page where they placed it they are happy and unaware that they need to do anything, and they will find the notifications on they talk pages only after the image is deleted and they come back to see what happen. --Jarekt (talk) 11:51, 8 July 2015 (UTC)

Wikidata update

I'm not sure if everyone knows but Wikidata just added a couple things related to Commons. Previously they just had Commons Category (P373) and Creator (P1472), but now they also allow for linking to Galleries (P935) and Commons Institutions (P1612). I'm not sure who participates at Wikidata but wanted to pass that along. Reguyla (talk) 15:02, 7 July 2015 (UTC)

Thanks for letting us know! --Steinsplitter (talk) 15:05, 7 July 2015 (UTC)

Yes thanks, so we made this informations more public on Commons pages!? ↔ User: Perhelion (Commons: = crap?) 20:50, 7 July 2015 (UTC)

Well its a start. The problem is this, since we can only link to one page in the otherwiki's box for commons, we now have to choose which one to link too, Category, Gallery, Insitution or Creator. We can link them all as properties to the item, but only one will be aligned to the Interwiki links under the other wiki's box. So, if a gallery exists that corresponds to an article, would we need to remove the "category link" from the other wiki's box and replace it with the Gallery that more directly relates? It seems reasonable to me to do that, but if we do, then it causes all the interwiki's to no longer link to the Category, so then we would need to add back any interwiki links that are appropriate to that category. So although we are getting better, there are still some problems to work through and some requirements to flush out. Reguyla (talk) 00:19, 8 July 2015 (UTC)

The Wikidata policy is to have separate wikidata items for articles and categories. Commons categories can only be linked to a Wikidata category item. Then you get to choose which of the other pages get to link to the wikidata article item. It's all slightly mad. --ghouston (talk)

That's all well and good but its not necessarily how its being used. And a lot of commons content hasn't been added to Wikidata yet. Reguyla (talk) 01:56, 8 July 2015 (UTC)

Yes; Wikidata advises to consider Commons gallery as a article/page and link to other articles/pages. It is a bit useless, and I need to create Lyriothemis acigastra to link at wikidata:Q2413777. I think it something Commons should decide whether category or gallery is important. I see no reason to give importance to gallery as it is not existing for all categories and the maintenance of gallery is tedious. J e e 02:07, 8 July 2015 (UTC)

The problem also exists that there are relatively few galleries compared to categories and galleries usually do not contain as much content as categories. Don't get me wrong, they are both good to have, but in some cases its going to be hard to choose which is the right one to link. Reguyla (talk) 02:22, 8 July 2015 (UTC)

It is not that simple. See for example, en:Libellulidae. Wikipedia has also en:Category:Libellulidae. So wikidata maintains wikidata:Q507694 and wikidata:Q6365089 and the second is linked to Category:Libellulidae. The first is more important; but not linked to Commons as no gallery exists. Creating a gallery for Libellulidae is nonsense as it is a wide topic. If we linked Category:Libellulidae too to wikidata:Q507694, it will become redundant. Further, it may not be possible to create duplicate entries in wikidata too. J e e 02:55, 8 July 2015 (UTC)

Galleries for wide categories can actually be useful, as visual guides to the areas covered by the different subcategories. For example, it might be useful to have a gallery Libellulidae with a few examples from each of the genera. - Jmabel ! talk 04:32, 8 July 2015 (UTC)

Good point, Jmabel. Currently Libellulidae is a redirect, and so wikidata will not accept such an entry. I'll try to create a page and try again. But still I'm not happy with these two "disconnected entries" in wikidata. I prefer a parent object linking pages and categories. J e e 04:45, 8 July 2015 (UTC)

I completely agree, its not simple at all and there are a lot of situations like you point out. Reguyla (talk) 03:03, 8 July 2015 (UTC)

The funniest thing is that they've provided an "Add links" link on category pages, which sets up an invalid link from a category to a wikidata article item. It's hard to tell that it's invalid since the interwiki links on the category will work perfectly. Occasionally somebody on Wikidata will revert some of these links for being invalid. Setting up a "correct" link may involve creating a new category wikidata item and cross linking it with the article item. It's too much trouble to do manually, and the final result is poor since interwiki links won't work except to other categories. My solution is to ignore Wikidata and use [[en:foo]] if I want an interwiki link, but that's also poor because it's English only. --ghouston (talk) 04:19, 8 July 2015 (UTC)

"Wikidata acts as central storage for the structured data of its Wikimedia sister projects" Maintaining two disconnected objects for a single topic (as in my example on Libellulidae) = non-structured data. Hope they will solve the issue (eg: by creating a parent object over it and keeping them as children) soon. Still then, Wikidata is not useful for Commons.J e e 04:29, 8 July 2015 (UTC)

@Jkadavoor: Passeriformes : this is a good exemple of the usefulness of a gallery for a wide content. -- Christian Ferrer 05:20, 8 July 2015 (UTC)
P935 is duplicate of direct Commons link for main space pages and could be deduced from category main topic for categories. Same for P373 when eliminating duplicates. --EugeneZelenko (talk) 14:08, 8 July 2015 (UTC)
- I don't think I agree. I see a need to have all 4 as separate entities but in a smart way. For example, its possible to have all 4 entities linked within a data element but that doesn't link to Commons for related interwiki's. If commons had its own Wikibox in Wikidata, rather than forcing it to use a single selection in the Other Wiki box, then we would be able to tie all 4 items to the appropriate entry on Wikidata and the interwiki's would be appropriately associated. This would also be of benefit because there would no longer be a need to link them as properties within the data element, they would be associated in the Commons Wiki Box. Reguyla (talk) 14:37, 8 July 2015 (UTC)

"Sports clothing" and "uniforms"

It looks to me like the Category:Sports clothing and its subcategories are now pretty much entirely disjoint from the descendants of Category:Uniforms. Obviously, not all sports clothing is a uniform, but it seems very odd to me that Category:American football uniforms -- which has uniforms in the category name! -- is not a descendant of Category:Uniforms. Does someone want to take on stitching this together (so to speak) in an appropriate manner? - Jmabel ! talk 21:39, 7 July 2015 (UTC)

Related to which, I am trying to work out how to categorize this very NSFW image (naked man in a body-painted replica of a Seattle Storm jersey) somewhere related to Category:Seattle Storm in a way that will not "surprise" someone with a definitely NSFW photo while looking up images of a sports team. - Jmabel ! talk 21:43, 7 July 2015 (UTC)
Make Category:Sports uniforms a subcategory of both? Note that sports uniforms are also known as "strip" or "kit" in British English. --ghouston (talk) 00:34, 8 July 2015 (UTC)
- Currently Category:Sports uniforms is a redirect to Category:Sports clothing, which seems wrong to me. Plenty of sports clothing is not a uniform. - Jmabel ! talk 01:40, 8 July 2015 (UTC)
  - Changed that, put a few obvious categories (but not yet any individual photos) under Category:Sports uniforms. If anyone wants to help out, undoubtedly a lot more belongs under there. - Jmabel ! talk 16:53, 8 July 2015 (UTC)

July 09

Lossless files on Commons

When I was working on some FP-candidates I got a few questions about why I had uploaded the files in png. They are original scans in TIFF format at a high resolution. I wasn't able to find any proper guide for when to use lossless versus lossy files on commons, so I've created one. For many this is second nature, but I think enough people will find it useful so I'm posting my work in progress here. Please judge all you want and try to give me feedback. I'll do my best to adapt the guide and see what can be improved or if it should be merged somewhere else.

Note: It is still lacking a number of sections that I wasn't able to just write of the top off my head. I'll be researching these and updating it.

Available here: Commons:Lossless
(I realize I should probably have a better name for is as well such as Commons:Lossy versus Lossless or something similar).

Best, -- CFCF (talk) 21:31, 6 July 2015 (UTC)

In regards to "Lossless files should not be used in articles such as on Wikipedia. If a file only exists in a lossless version a new lossy version should be uploaded and used. This is in order to decrease load on the Wikimedia servers, both bandwidth and processing power used for rendering. Additionally it is better for the end user, and especially so when the end user has limited bandwidth capacity." - Tiffs thumbnail as jpegs so the bandwidth argument doesn't apply to them. You should not worry about processing power required generally speaking, we have servers so that they can be used (What takes more or less processing power isn't exactly straightforward either, I would recommend against doing anything because of processing power required, unless you are actually measuring the processing power or you are encountering some sort of limit like the large gif images don't thumbnail limit) [Obviously if you do notice something that's unambiguously exploding the servers, you shouldn't do it]. Bawolff (talk) 01:20, 7 July 2015 (UTC)

Okay, I didn't know TIFF thumbnailed as jpeg. Weren't there a number of issues concerning TIFF thumbnail generation as well? When it comes to pngs I know for a fact that they thumbnail as png, so they shouldn't be used for sake of the end user. I'll try to update it to cover that. As for the topic of computation needed to present a file I'm primary looking out for the end-user, I'll also try to make that more apparent. CFCF (talk) 07:15, 7 July 2015 (UTC)

P.S. The goal of the guide is to make more users upload and work on lossless files rather than the other way around, but to do so in a reasonable manner. I wonder if MediaWiki would support thumbnailing PNGs as JPEG? CFCF (talk) 07:21, 7 July 2015 (UTC)

What does computation needed to present a file have to do with the end-user? Is there any system that can handle HTML 5 that takes non-negligible time to process a thumbnail-sized image, either PNG or JPEG?--Prosfilaes (talk) 07:37, 7 July 2015 (UTC)

I'd really like to see numbers. There's a rule of thumb in the computer world that you should measure before optimizing and after, because many optimizations aren't, or aren't in real circumstances.--Prosfilaes (talk) 08:08, 7 July 2015 (UTC)

When it comes to PNG vs. JPEG the difference in filesize is very significant (although I'm unaware of difference in computation needed - it may be more significant for mobile). I was planning on adding an example where I measured page load between PNG and JPEG thumbnails in an image-heavy article (I just need to create and example with a sufficent amount of png/jpeg files that are available in both formats), so I will try to get those numbers. This might not be an important issue for the servers, but said filesize does matter a whole lot for the end user. The Swahili Wikipedia prohibits use of larger images than circa 100px wide because of the extra bandwidth cost this incurs on users (important due to the heavy mobile readership on that Wiki), and when creating a download of an entire Wiki such as Kiwix the difference in size between JPEG and PNG is very noticeable (they might even need to convert everything to create JPEGs of all the files, I do not know).

That said, if TIFF does thumbnail as JPEGs and server capacity and computation are a non-issue then that is a strong incentive to use TIFF over PNG, at least until commons supports JPEG thumbnailing of PNGs. See below comment by Revent. I'm increasingly feeling this could actually do with being covered in policy. CFCF (talk) 10:00, 7 July 2015 (UTC)

The TIFF scaling problems are at least 'supposedly' fixed, but TIFF really isn't a great format, to be honest... a specific TIFF can be all kinds of different things, including a 'container format' that holds JPEG images, or a 'GeoTIFF' that includes georeferencing metadata. I think the only 'real' use of TIFFs should be for 'archival' copies of images that were originally provided in that format, for the purpose of being a 'first generation' source for editing. There is just too much variation in what a TIFF can actually 'be', and varying levels of support for the different extensions, for it to be appropriate for general use. Revent (talk) 09:57, 7 July 2015 (UTC)

GeoTiff is hardly a point against TIFF files, JPEGs can also have all sorts of metadata in them (Have you read the exif standard? IMO its an utterly insane approach to adding metadata to a file). Bawolff (talk) 11:18, 7 July 2015 (UTC)

@Bawolff: Yeah, I didn't mean that GeoTIFF is a 'bad' thing, just giving it as an example of how TIFFs can have all kinds of odd features that are not widely supported. Revent (talk) 12:17, 7 July 2015 (UTC)

Just as a further point on this, I think it's worth noting that some web browsers (Google Chrome, notably) do not include native support for displaying TIFFs... when you view a file page on Commons for a TIFF file, you are actually viewing a JPG thumbnail, even if using a browser (like Safari) that supports TIFFs. If someone tries to embed a TIFF in a webpage it will not work reliably. (Unfortunately I can't demonstrate this here, since embedding HTML in Commons pages is disabled). Effectively, however, TIFF-only images are not reusable on the web at full resolution unless converted and stored locally. Revent (talk) 12:47, 7 July 2015 (UTC)

True, although I'm not sure how big a deal that is in practise. For smaller tiffs you can get MW to make a jpg (or even png) thumb at full resolution. Larger tiffs will run into limits when making very large thumbnails, but its not like people were going to embed a 60+ MB file directly into a web page anyways. Bawolff (talk) 15:34, 7 July 2015 (UTC)

Hi, I think TIFF or PNG for large files should only be used as archive. For regular display, JPEG should be used. There is no shortage of disk space, so there is no reason not to have 2 versions. Regards, Yann (talk) 07:57, 7 July 2015 (UTC)

Yann, do you mean there is no reason not to have two versions?CFCF (talk) 10:01, 7 July 2015 (UTC)

Yes, sorry. Yann (talk) 10:03, 7 July 2015 (UTC)

To be precise, I think that the JPEG should be nominated for FPC. So the comments asking why you nominating PNG files were right. Yann (talk) 10:28, 7 July 2015 (UTC)

Having two versions can sometimes cause confusion with syncing categories/etc between both. So its not totally without a downside (imo). As for nominating PNGs for FPCs, keep in mind that pngs have different sharpening settings applied on thumbnailing, so the png thumbnails will look mildly softer than thumbnails of a jpeg version of the image. Bawolff (talk) 11:18, 7 July 2015 (UTC)

Note that TIFF is not necessarily uncompressed nor is it necessarily lossless. Also, the masters of non-professional photographs are frequently JPEGs, but one should still not work on a lossy format; if you're going to be doing multigenerational editing, intermediate steps (and probably the final one) need to be lossless.--Prosfilaes (talk) 08:08, 7 July 2015 (UTC)

I don't think PNGs should generically thumbnail as jpegs. JPEGs are optimized for a specific type of image (photo-realistic images with lots of gradual transitions in them). JPEG Compression artifacts are much more noticeable in non-photo images, which is usually what PNG is used for (Also, alpha channel not an option in pngs). If we were to do something like that, I think we would have to be able to select on a per-image basis what the preferred output format is instead of making all pngs render as jpegs. In terms of optimizing for bandwidth - there's probably a lot of things we can do. I know WP Zero (and maybe mobile?) was experimenting with higher compression jpegs. Gilles was looking at implementing what facebook does to reduce size of colour profiles, but there's probably a lot of other things we could do if we took a hard look at our image thumbnailing process. Bawolff (talk) 11:18, 7 July 2015 (UTC)

The main point though is that while some websites get lazy and just use "img width= x height= y" to create a thumbnail, we do not do that. If we did that a lossless humongous file would take forever to load as a thumb. Delphi234 (talk) 06:47, 10 July 2015 (UTC)

July 07

FoP saved

Thanks everyone for helping to save the Freedom of Panorama in Europe -- The result: "panorama freedom being restricted was not an idea from the commission - it was apparently a misunderstanding […]" -- Rillke^(q?) 13:51, 9 July 2015 (UTC)

Yes, Thanks everyone! --Steinsplitter (talk) 13:54, 9 July 2015 (UTC)

+1. It's back to status quo for now, but there's still a chance to push the original proposal of EU-wide FOP (even though that has been rejected for now as well). --El Grafo (talk) 14:03, 9 July 2015 (UTC)

There is always a chance but my understanding is that it has been explicitly rejected today.--Ymblanter (talk) 14:56, 9 July 2015 (UTC)

'Explicitly', yes, the source I saw said 40 out of 751 voted for it... that's just over 5% for the math-impaired.

Revent (talk) 00:14, 10 July 2015 (UTC)

July 11

Peer review and document improvement request

This is a Peer review request to seek broader input to improve page: meta:Help:Form I & Affidavit (Customised for relinquishment of copyright as per 'free cultural work' definition) an option available under (Indian) Copyright act 1957 rules.

Mahitgar (talk) 07:06, 11 July 2015 (UTC)

Central American / South American photos

I need help and have tried other avenues but am stymied. The Copyright law of Brazil article tells me nothing and I cannot access the source. There is no Copyright law of Guatemala article, Nicaragua, Uruguay, etc. The Media Copyright Questions page suggested I ask here. So, here is the situation. I wrote an article on Primer Congreso Interamericano de Mujeres and I would like to do a strip of photographs like were done on this article: Pan-American Conference of Women.

The only photos of the conference I find are here PRIMER ENCUENTRO INTERAMERICANO DE MUJERES, GUATEMALA, 1947. They were taken in Guatemala in 1947, are they useable?
I believe that Argentina after 25 years is as PD so this one María Teresa Ferrari should be useable. Can you confirm?
This one is really exciting as it is the Chilean delegate's visa issued for the conference. María Rivera Urquieta She was Chilean, but the Visa is Brazilian. So do I go by Brazil or Chile? I have written a stand alone article for her María Rivera Urquieta which I would also like to use the photo for. Can I use it?
one for Bolivia here
and one from Colombia [6]

If anyone on here would like to help with this project, photos of any of the women in the article would be great. I asked a couple of editors on commons and no one knew the answers and suggested I post here. Some I am looking for specifically are: the very first Mexican movie star (Elena Sánchez Valenzuela); an MP in Canada (Beatrice Brigden); the first activist for disabled person's education (Eloísa García Etchegorken), Uruguayan; the first female lawyer in Nicaragua (Olga Núñez Abaunza); Sue Bailey Thurman. Any help would be greatly appreciated. I also am not sure how I get a response to this but if anyone is able to help, can you please notify me on my talk page on Wikipedia? Thank you SusunW (talk) 17:02, 5 July 2015 (UTC)

I found a photograph for the Canadian (Beatrice Brigden), which I believe was taken around the time of the conference or earlier, based on the clothing, hair style, etc. and the fact that I found a video of her from the 1970s. The poster gives his source as the Archives of Manitoba, but I was not able to find the photo there. [7] SusunW (talk) 23:50, 6 July 2015 (UTC)

Is there no one who can help or refer me to someplace/someone else to try? SusunW (talk) 00:25, 13 July 2015 (UTC)

You should probably try at Commons:Village pump/Copyright. - Jmabel ! talk 06:34, 13 July 2015 (UTC)

Replace picture with watermark

Hi, I have uploaded a new version of a file, without watermark. Can any administrator delete the two older versions (normal and not-interlaced). Here is the file, thanks a lot. https://commons.wikimedia.org/wiki/File:Giralda_desde_torre_del_oro.jpg

I see no reason to delete those. What might you have in mind? - Jmabel ! talk 06:35, 13 July 2015 (UTC)

* It is a matter of privacy: I do not want my name and surname to appear on that photo. I have already done it with all the other pictures I uploaded, but I forgot to do it with this one. Since I have uploaded a new version of the picture without watermark, everything should be ok and the image will anyway be available. — Preceding unsigned comment added by 5.96.21.147 (talk • contribs)

Warped image?

Some time ago I uploaded this image having cropped it, put it on this page and it looked fine. Some shortish time later I was again looking at the page and it seems to me (and still does) as if the image had been horizontally compressed (or vertically expanded). I am pretty sure it was OK when I put it there. I had the same trouble with a pair of images I cropped today that looked fine then maybe an hour later it was as if they'd been sort of stretched. It was just as if some bot had come along and made an adjustment. Or is my cropping bad?

Or, am I imagining things? The more I look the odder the images look! I tell myself for a moment they look OK and they look OK then go off again. Would someone please look at these two images and say if the subject looks scrunched up. File:1956 Rolls-Royce Silver Wraith Touring Limousine (H.J. Mulliner) (15629885401).jpg and File:1956 Rolls-Royce Silver Wraith Touring Limousine (H.J. Mulliner) (15608899086).jpg. My vision is not perfect and I may be imagining it all. Thanks, Eddaido (talk) 09:51, 11 July 2015 (UTC)

The images look fine to me. Sometimes, when a new version of an image has been uploaded, it takes time for the thumbnails to be updated. — SMUconlaw (talk) 11:06, 11 July 2015 (UTC)

@Eddaido: This is, I think, a 'side effect' of that when you are looking at the file page, you are not seeing the actual image itself, but a thumbnail generated by the server... there is an 'image size limit' for file descriptions pages that you can set in your preferences, and when changing the aspect ratio of an image you can end up seeing a thumbnail with more 'zoom' on the file page itself. Looking at the actual images themselves, they look fine. Revent (talk) 23:00, 11 July 2015 (UTC)

Thank you both very much. Eddaido (talk) 05:26, 12 July 2015 (UTC)

It corrects itself the following day. It takes the new image and stetches or shrinks it to fit the old file dimensions. It can be very annoying. Also it may continue to display the older image if you just adjust the contrast and re-upload it, and maintain the same dimensions, it makes you think you loaded the old image by mistake. --Richard Arthur Norton (1958- ) (talk) 07:22, 13 July 2015 (UTC)

- See Help:Purge for instructions on how to force creation of nwe preview images. --El Grafo (talk) 11:01, 14 July 2015 (UTC)

July 12

Nicolas Henri Jeaurat de Bertry (1728–1796) request

Hello,
Could someone upload images of paintings by Nicolas Henri Jeaurat de Bertry (1728–1796), presumably in the public domain because of age, located here and elsewhere?
Thanks in advance. 62.233.34.179 04:42, 12 July 2015 (UTC)

Meanwhile, I created Creator:Nicolas Henri Jeaurat de Bertry. Regards, Yann (talk) 22:53, 13 July 2015 (UTC)

Unfortunately the images on that site are all very low resolution, and it seems that other sources for his works all seem to have horrible watermarking. Revent (talk) 02:07, 14 July 2015 (UTC)

I added a few higher quality images from misc sites to the Nicolas Henri Jeaurat de Bertry Category. As Revent said, those images are low resolution, so it would be better to just use the artnet.fr images links with image searches (like google image) to look for higher quality versions. Offnfopt^(talk) 04:08, 14 July 2015 (UTC)

I added a French description. I think it is better to use a JPEG to display on Wikipedia. BTW there are plenty of HR copies on the Net: [8]. And I uploaded 2 more. Regards, Yann (talk) 09:36, 14 July 2015 (UTC)

July 13

hotcat-bug

in urdu wiki pedia hotcat bug [9]. hotcat removed curly Brackets in all templates.--Obaid Raza (talk) 11:22, 14 July 2015 (UTC)

Wikimania 2015

Wikimania 2015 is starting this week in Mexico City. I and probably many other Commoners will be there. I am curious who else is coming, and for those that do, if you run into me please introduce yourself. --Jarekt (talk) 13:04, 14 July 2015 (UTC)

Unfair, arbitrary block (and in the middle of a discussion)

This is User:Tm. I have just been blocked for two weeks by the administrator User:Blackcat] as being envolved in edit warring, per the facts depicted in my talkpage and the envolved administrator and are related to the Category:Lisbon Metro] and its subcategories.

The administrator started to move this categories claiming (after being asked to stop this moves without discussion) that we was doing administrative work. I reverted his moves and was threaned with an imediate block, per warning on my talkpage. After being warned, i showed Blackcat, that his moves, envolving language of categories(per policies related to categories and language categories), capitalizations of the word metro (metro or Metro) and the positions of the word stations (ex. "Lisbon Metro stations"or "Stations of Lisbon metro") were against the standardizations in articles in english wikipedia or the other commons categories related to mass transit like Category:Rapid transit by country.

The mutual reversions continued, but i, as a form of trying to stop this futillity, suggested that instead of threatening to block those who disagree with his edits as a normal user (and not as he claimed admistrative and maintenaince work), he should open a category discussion to see if he had a consensus (or close to that) and even gave some users ( that have previous editions in the Lisbon Metro) that he could contact, like User:Tuvalkin, User:Jcornelius and User:Ajpvalente.

What did Blackcat did. He imediatly blocked me, in the middle of the discussion, unfairly, just to "win" win the argument. As a show of what is to me badfaith, he even blocked me from my discussion page and email acess, and after the block moved this categories to what he thinks is right. Whould someone revert this abuse of power and overbearing by this administrator? 2001:697:2F49:0:A92A:64D3:4FA:96A7 22:34, 13 July 2015 (UTC)

The said user has a long story of edit warring; it was not a block lightly administered, 'cause I even warned him. I reminded him that this is Commons, not en.wiki, where the naming conventions are different. As response, he kept on reverting. Since this is not the first time he keeps on edit warring (it's the first time I see him doing that but he did with other admins) I blocked him for two weeks, and considering that this is not the first time he is blocked for the same reason I have been rather light. -- SERGIO ^{(aka the Blackcat)} 22:38, 13 July 2015 (UTC)

I only linked to the en wiki article of Lisbon Metro, all the others are in Commons. What about the categories in commons that i ve showed you support the situation as was before your moves? 193.236.47.73 22:42, 13 July 2015 (UTC)

@Blackcat: While it might have been better to ask another administrator to look at it, instead of blocking him yourself (because of the ongoing dispute), it's a bit hard to fault blocking an editor who continues to revert (half a dozen times or so) immediately after being told that continuing to do so would result in a block, instead of bringing the dispute to the wider community. (For the sake of 'disclosure', I myself warned Tm for upload warring less than two weeks ago) That being said, I've just applied blocks of the same length (two weeks) to the IPs Tm has used to edit this page, for block evasion. If Tm wishes to appeal his block, or even merely the restriction from editing his talk page, there are other ways to do so than using an IP address to evade his block. Revent (talk) 00:25, 14 July 2015 (UTC)

@Blackcat: Could you answer my question on Tm's talk page rather than pursuing this here? A block clarification or appeal is better placed there. I pause only to note that Tm was blocked for ~~1 day~~ 1 hour at the beginning of last year. An 18 month old block is weak evidence of a "long story of edit warring" as you have asserted. Thanks --Fæ (talk) 22:53, 13 July 2015 (UTC)

I have no idea about the matter at hand and don't have an opinion of whether a block is justified or not. But blocking a user to "win" an edit war is very bad taste and in my opinion an abuse of admin power. If you think a block is in order, go through the same channels that any other user has to go through. --Sebari (talk) 01:18, 14 July 2015 (UTC)

I didn't block him for winning a discussion. As I told, the user has a story of reverting without discussing. In this case he was telling me "let discuss" but meanwhile was reverting (btw in technically wrong way), so I warned him not to keep on reverting. The block was not for winning the discussion, but to prevent him from keeping on his edit war. If he had only discussed there wouldn't have been any block. -- SERGIO ^{(aka the Blackcat)} 07:55, 14 July 2015 (UTC)
PS IMHO the IP used by TM shouldn't have been blocked. When I blocked him I prevented him by mistake writing his own user page. Now I removed that limitation.

@Blackcat: The problem is that it is very hard for an outsider like me to distinguish between that and not to see a possible conflict of interest. Even if you are right (or think you are right), I would appreciate if you asked another admin to handle it in cases where you are involved yourself. (The same is true for all other admins.) --Sebari (talk) 12:35, 14 July 2015 (UTC)

Srittau, ok. To avoid further controversies I unblocked the user. But I wish that such reverts come after discussing (there might be a good reason for moving a topic to a more appropriate name) and not while or instead. -- SERGIO ^{(aka the Blackcat)} 17:46, 14 July 2015 (UTC)

To prevent this from continuing, I request that User:Blackcat cease from unilaterally moving metro station categories (I too believe his moves are improper and against consensus) and go to CFD before making these controversial moves. Pi.1415926535 (talk) 20:23, 14 July 2015 (UTC)

Pi.1415926535, what I did is perfectly consistent with the category scheme, thus you're kindly invited to have a look at it before insisting on this topic. Thanks. -- SERGIO ^{(aka the Blackcat)} 07:46, 15 July 2015 (UTC)

Yes, that style is standard for certain fields (hence those by-field category schemes) for high-level categories. But nowhere there or in Commons:Categories do I see any evidence the naming style is you claiming is in any way policy. You have had multiple established users ask you to stop moving categories and discuss first instead; your response each time has been to act superior and condescending (unless I am reading it incorrectly, your recent post on my talk ended sarcastically - "Thus I suppose that you infere that metro stations make exception from the rest of Commons? Let me know, please, and show me where it has been decided. Waiting for your response." - and was rather rude) and continue to make move pages against protest. That is not behavior befitting an admin. Even if you are correct in moving these pages, since there is controversy over whether it is correct, the burden of proof is on you. You did not provide any explanatory summary when moving categories, so you need to provide that proof at CFD before making any additional moves. If you insist on continuing to move without a proper discussion or at least providing direct proof that your moves are correct, I cannot see any way forward that does not involve seeking administrative action to create a discussion that you are obliged to participate in. Pi.1415926535 (talk) 12:33, 15 July 2015 (UTC)

Actually I stopped moving waiting for a pronouncement. Are there any evidence that stations of metro make exception from high-level categories? That's what I wish to know. The rest is out of focus. If you claim for exceptions getting out of an established paradigm, the burden of the proof is not on me. I simply stopped moving out of courtesy, not because the naming is wrong. -- SERGIO ^{(aka the Blackcat)} 14:01, 15 July 2015 (UTC)

You are correct about the timing; I apologize for misreading timestamps. I don't understand your claim that there is a defined paradigm that is being violated - the naming style used for certain high level categories is not policy outside those categories, and so far as I can tell the metro station categories are not subject to any existing rule. Since you are the one wishing to move these, please just open a CFD section and let an actual consensus be set and/or unambiguous policy found. I don't understand why you refuse to go through that established process. Pi.1415926535 (talk) 14:39, 15 July 2015 (UTC)

Then, since I am sick and tired of disputes about naming which I find silly (not because of you, mind you, but just because argueing about synthiax is a waste of time) what about a general discussion in order to uniform the names and give consistency even to the lower-level categories (provided that for me there are not rank difference in categories)? -- SERGIO ^{(aka the Blackcat)} 16:28, 15 July 2015 (UTC)

That's a discussion that would affect thousands if not tens of thousands of categories due to the multiple naming schemes currently in place. I can't imagine that would take place as anything but an RFC, and that's a huge amount of work and arguing about syntax that neither of us want. At this point I think the simple solutions are a) all involved agree to stop renaming metro station metacategories altogether, which results in an inconsistent but no worse than before array of names, b) revert back to the names used before you started moving (largely consistent, but probably not to your satisfaction), or c) hold a CFD just for metro station metacategories without trying to apply the results elsewhere. Which do you prefer? Pi.1415926535 (talk) 16:49, 15 July 2015 (UTC)

The third would be the best solution, though the main goal should be having all the names consistent -- SERGIO ^{(aka the Blackcat)} 18:52, 15 July 2015 (UTC)

July 14

Upload wizard bug

There seems to be a bug in the upload wizard. I often upload images as e.g. "Marshalls Heath 1", "Marshalls Heath 2" etc. For the last two or three weeks it has changed the file name of the highest number (which is normally the first one uploaded) to 1, so that I would then have e,g two files called "Marshall Heath 1". I then have to change the name back manually in order to avoid the wizard refusing to upload because of duplicate file names. It is not a major problem once you are aware of it, but it would be helpful to get it fixed. Dudley Miles (talk) 19:20, 14 July 2015 (UTC)

I have just found that I described the problem wrongly. I tried to upload three files which failed on the first attempt, Marshalls Heath 4, Stocking Springs Wood 7 and Stocking Springs Wood 8. They came up with no Marshalls Heath 4 and Stocking Springs Wood 8 twice. I had to cancel the upload as the preview is also not working so I did not know which file was wrongly named. There are a number of problems with the upload wizard at the moment - it is slow, if there are more than about five files some fail, preview not working and changing file names. Can some kind expert have a look at this? Dudley Miles (talk) 19:44, 14 July 2015 (UTC)

The problem you are reporting sounds like a potential issue in the code of the UploadWizard software. If the problem is reproducible, it would be nice if somebody who has this issue could send the software bug to the 'Phabricator' bug tracker by following the instructions How to report a bug, in this case under the project 'MediaWiki-Extensions-UploadWizard' (direct link; see the Phabricator help for account information). This is to make developers of the software aware of the issue. There is also a full list of reported problems and enhancement requests for UploadWizard. Thanks! --AKlapper (WMF) (talk) 20:29, 15 July 2015 (UTC)

July 15

Bigotry

Resolved

NeverDoING has created a Category:Eurocentrism as subcat for such things as 'discrimination'. It contains only subcats that have to do with European federalism and further down sports manifestations on the whole European continent. I think this user needs to be banned for good. I really do not think that this kind of anti-European bigotry should be tolerated. Jcwf (talk) 03:41, 15 July 2015 (UTC)

I doubt anyone needs to be banned for this, but it sounds like lousy categorization. - Jmabel ! talk 06:14, 15 July 2015 (UTC)
@NeverDoING: - Jmabel ! talk 06:16, 15 July 2015 (UTC)
Deleted. Nothing to be done. Yann (talk) 13:33, 15 July 2015 (UTC)

Two files into one

Hi, I can't get how to keep two consecutive files into one, like this one. Basically I have two pages of a leaflet in PDF format and I want to keep both pages under the same name, so that there would be the option to navigate to any pages. I have already uploaded the first page here and can't get a way to insert another page under this name. Please help me out. Thanks. Tanweer Morshed (talk) 10:46, 15 July 2015 (UTC)

@Tanweer Morshed: You need to create a multi-page PDF. The MediaWiki software will then automatically recognise it as being so, and will allow you to navigate between the pages. If you're unable to do it yourself, just upload the second page as a standalone file, and I'll join the two pages and re-upload this newly created document under the original file name. (Ping me here when that's done.) Thanks, odder (talk) 12:38, 15 July 2015 (UTC)

Hi odder, here is the second page of the PDF. I can create multi-page PDF but I am not an admin here and so can't delete the existing first page and re-upload the multi-page PDF under the same name. It would be great if you join the pages and upload under the original name. Thanks. Tanweer Morshed (talk) 16:48, 15 July 2015 (UTC)

@Tanweer Morshed: This is now

done. odder (talk) 17:27, 15 July 2015 (UTC)

Thanks a lot odder! :) Tanweer Morshed (talk) 07:41, 16 July 2015 (UTC)

Commons:Naming categories

(It seems there is no really actual concrete guideline here as in Wikipedia.) The actual related guideline seems only this: Commons:Categories #Category names. I would like to ask, because I'm not sure to proceed here: Category:SVG flags sub-cats are with very uncommon hyphen and spacing ( - ) for naming subdivision⁉ I mean this is also topologically incorrect (alls cats are by an IP) and we should rename all this⁉ ↔ User: Perhelion (Commons: = crap?) 14:21, 15 July 2015 (UTC)

Very unusual naming schema, although I have been guilty of using similar schemes in the past. I'd recommend to rename them indeed to something more commonly used and "natural". --Sebari (talk) 16:17, 15 July 2015 (UTC)

Says it's public domain - but not 100% clear why?

Can a national library listing an item as public domain be enough to consider it public domain? In particular, I'm thinking of http://gallica.bnf.fr/ark:/12148/btv1b7003340c/f8.item.r=Otello%20verdi - the underlying work is clearly public domain, and if you click on " [Othello : Acte I : une place près du château, une taverne : maquette ..." it pops up a box stating clearly "Droits : domaine public". But, normally, a photograph of a 3-dimensional work would be copyrighted. Thoughts? Adam Cuerden (talk) 18:58, 15 July 2015 (UTC)

We assume that it is a picture made by their staff and released under the public domain. I uploaded several like these, e.g. File:Armes de Brunehilde portées par Lucienne Bréval.jpg. Regards, Yann (talk) 20:01, 15 July 2015 (UTC)

Lua error in Module:Fallback

Bugzilla: T106207

What in the world is going on with File:OHMap-doton-Leipsic.png? It looked fine when I loaded the page, but when I edited it (just adding a category), the normal description page got replaced by a mess (see screenshot at right). I self-reverted, thinking I'd made some sort of mistake, and once again all was fine. I then re-added the category, and mess returned. See File:OHMap-doton-Pandora.png for an example of what this kind of page is supposed to look like. Nyttend (talk) 12:53, 16 July 2015 (UTC)

I have seen this about 3 times in the last day. ~~The images pages display correctly on refresh.~~

Correction, after uploading File:Aquatic and wetland plants of southwestern United States (1972) (19126898504).jpg, refreshing the screen did not clear the error. I had to make an edit (changing a category) before the page displayed correctly. --Fæ (talk) 16:47, 16 July 2015 (UTC)

I can confirm this (never seen this before). Maybe this in relation/combination with option of live-preview (wpuselivepreview in the settings Special:Preferences#mw-prefsection-editing, for me this solve the problem for the examples). Maybe let a hint on the module talkpage. ↔ User: Perhelion (Commons: = crap?) 17:23, 16 July 2015 (UTC)

Images from historical books

461,828 R Files from Internet Archive Book Images Flickr stream

Example full page book plates
Fashion, 1830s
Illustration from The History of Ireland, 1884
Score from The Tyrant Reformed, Étienne Méhul, 1790
Wild flowers, 1920
W.G. Grace, 1899
A killed giant gorilla held by three negroes, Camaroon, 1910
Physical training (long exposure photo), 1917
Dissection illustrations, 1877
Map of the Copper River, Alaska, 1880
USS Bear, Alaska, 1890
Sculpting an extinct Brontotherium (Megacerops), 1917
Slovak girl in Sunday attire, Marianne Stokes, 1909

As a small experiment, I am running an test batch upload from the Internet Archive Flickrstream. These are problematic, but the overall value of content in well within our mission to search out educational content; some images being of remarkable value for illustration or reuse. I am limiting uploads to images which are at least 2,500 pixels on the longest side. This removes at least 95% of potential content, and cuts out lots of lower quality images or small diagrams. However there is a lot of content available, with over 3 million images in this Flickrstream, so any mass upload needs to be handled with caution.

Things you can help with:

Rotate, many full page images need a 90° or 270° rotation. This needs a human visual check to decide.
Categorize, the tags available are hard to map to anything useful. I am defaulting to identifying the book publication year and adding the associated Commons category. Further automated mappings are possible and could be fairly easy to do using normal Commons text search.
Speedy delete blanks, many scans of books include their blank pages. It might be possible to find ways of detecting these, however as some scans have bleed-through from the other side of the page, or include edges showing the rest of the book, reliable automated filtering is impossible.
Check through optical text recognition, some scans include optical character recognition for inscriptions. These may be poor or even incomprehensible. I believe it is worth including these on the upload, however user feedback would help assess it further.
Upload full images over fragments, a few diagrams have been automatically cropped to an internal frame mark, this can leave out valuable context such as chart legends or dates. For example this temperature chart covering 1908-1913 was uploaded as the chart line area only and was overwritten by taking the full page image from the source link (View Book Page).

The plan is to run an initial couple of thousand images through this process, but the point of this informal test is to see if a larger batch upload with image size filtering is practical, whether it is practical to add more types of filtering, or if it would absorb too much volunteer time to be worthwhile. The upload is relatively slow, about one a minute, so I can adapt the test if problems are raised.

To see a list of images in this batch that still require a human review, try this CatScan report. This upload is not in affiliation with any group or organization, just an independent unpaid Commons volunteer having a go at it, so be kind in your feedback. --Fæ (talk) 14:34, 14 July 2015 (UTC)

Despite your bad words on IRC, I congratulate you for your work here. ;o) Yann (talk) 14:41, 14 July 2015 (UTC)

@Fæ: FYI, just scrolled through all 1200 or so in the "Files from" category, and deleted ~~three~~ four that were blank pages, which is a reasonably low level of 'errors' for this kind of thing, I think. Revent (talk) 20:13, 14 July 2015 (UTC)

That's encouraging, in fact the general quality of the images resulting from filtering at 2,500+ pixels is better than I expected and seems to be acting as a filter for full page size images.

I'll keep letting this run at the "slow bot" pace of 1 per minute for a few days, before thinking about what extra "fixes" could be automated. One quick fix was mapping the "booksubject:" tag to categories, whenever they happen to exist with the same name, and are not marked as diffusion categories. --Fæ (talk) 22:34, 14 July 2015 (UTC)

Sorting by source book

Hi @Fæ: Can I suggest that adding a category for the source book would be useful, as eg User:Metilsteiner had been doing in the sub-cats of Category:Scans from the Internet Archive for his uploads from the Internet Archive? That gives people a way to quickly see what else we have from a particular book that might be related, if they find an image that they're interested in. Jheald (talk) 20:41, 15 July 2015 (UTC)

It's an idea, however taking the book title field (which appears in the description text) might match to naff names if done automatically, say, "My life", which might match existing categories and dump irrelevant stuff there. The IA identifier is more useful, and should provide a unique and reliable way of filtering post-upload. For example using the normal Commons search with insource:/Identifier''': euphrosineouletymhul/ (direct link here) provides a nice list of all the pages from the 1790s Euphrosine opera score. ~~If only cat-a-lot still worked in search results pages, these would be easy to instantly put in a new category by hand.~~

I'll avoid using auto-created categories for the moment, as it could get a bit mad, but I'll think about what we might do as post-upload housekeeping. --Fæ (talk) 21:01, 15 July 2015 (UTC)

Struck my comment, using the search against the identifier, I just added Category:Euphrosine to these images in one "select all" swoop using cat-a-lot. It does work, I just have a conflict in my custom settings and swapping to another userskin tidies that up. --Fæ (talk) 01:02, 16 July 2015 (UTC)

After a bit of thought, I have started to include an easy search link using the IA identifier ("bookid"). For example File:Aquatic and wetland plants of southwestern United States (1972) (19741933292).jpg uses the identifier "aquaticwetlandpl00corr" and the image page now includes this search. I believe this is a lot safer than letting a script automatically create categories from varied book title fields without human intervention. This gives volunteers a very easy way of finding all images from a scanned book, and using cat-a-lot to group them into a new category should they wish to name one. A key benefit from this approach is that if others upload images from IA, or have already, then so long as they have included the IA unique bookid in the description, this same search should find them. --Fæ (talk) 16:14, 16 July 2015 (UTC)

Comment At least a Category:Annual report of the Bureau of Ethnology to the Secretary of the Smithsonian Institution would be useful. Regards, Yann (talk) 16:15, 17 July 2015 (UTC)

Oddities

Something rather odd has happened with this one: File:The greater abbeys of England (1908) (14782770494).jpg -- upload script seems to have reversed the aspect ratio? Jheald (talk) 20:57, 15 July 2015 (UTC)

It was rotated by 90° after upload, is that what you mean? It's also a good example of where it could be improved by re-uploading the original page, or a bigger crop, as the image has had most of the sky cut off by the simplistic 'frame-detecting' software that IA used to populate the Flickrstream. --Fæ (talk) 00:54, 16 July 2015 (UTC)

Progress reports

Thanks to everyone who has been improving this batch upload. There has been a lot of interest and improvement in just the first 24 hours!

The project has been added to the GLAM dashboard for reporting. Follow the links below for an daily summary of how these images are being used and ideas for improvement.

By the way, I crashed in to the Flickr maximum API usage rate today (I had about half an hour with mixed errors including "connection refused"). The number of API "queries" is limited to 3,600/hour and the previous hour was reported as peaking over 2,800. Most of the API queries are not from the image upload itself, but from checking the sizes of all possible candidate images, 95% getting filtered out. I am introducing a 30 second lag after each successful image upload so I can stay around a safe usage rate. --Fæ (talk) 16:29, 15 July 2015 (UTC)

Dashboard reports

Project contributors

Edits	#	Volunteers
1000+	69	Fæ · FlickreviewR 2 · Wieralee · Hilohello · Helmy oved · WayneRay · JMCC1 · Ruff tuff cream puff · Kilom691 · Ruthven · WFinch · Thiotrix · Túrelio · Animalparty · Lotje · Pmau · Deadstar · Tuvalkin · Jochen Burghardt · MILEPRI · Kersti Nebelsiek · Elisfkc · Broichmore · MPF · Mutter Erde · Smooth O · De728631 · Jim.henderson · Takeaway · PeterWD · Themightyquill · Abyssal · Strakhov · Florn88 · Rodomonte · NeverDoING · MKFI · DenghiùComm · Deanlaw · Bohème · Wolfmann · NearEMPTiness · Taterian · Kürschner · Tm · GeoWriter · Jmarchn · Rmhermen · ВоенТех · Ethically Yours · Allforrous · P199 · BMacZero · Orchi · Jarould · Laura1822 · Judithcomm · Rudolph Buch · Mindmatrix · Elgewen · Jmabel · Robert Weemeyer · Ashashyou · Materialscientist · BD2412 · Zaccarias · Butko · Albertomos · PlanespotterA320
100+	249	User-duck · Partynia · Steinsplitter · Minerv · JMK · BoringHistoryGuy · Airelle · Arnaud Palastowicz · Charles Matthews · Tyk · DALIBRI · Herzi Pinki · Cathy Richards · Zhuyifei1999 · Archie02 · Pixeltoo · Jarble · Misigon · Shakko · Geagea · INeverCry · Ziggyfan23 · Warburg1866 · Nonenmac · Ciaurlec · Hiddenhauser · Revent · Ww2censor · Jbribeiro1 · Jane023 · Henxter · Hansmuller · Joostik · Choess · Reykholt · Micione · Andy Dingley · Monopoly31121993 · Jonund · CAPTAIN RAJU · Metilsteiner · Magnolia677 · Beko · Clusternote · Till.niermann · Michael Barera · Sminthopsis84 · BrightRaven · TwoWings · Closeapple · Verne Equinox · SpiderMum · Brigade Piron · DePlusJean · Magik Johnson · Natubico · Chatsam · GeorgHH · JuTa · O484~enwiki · Borvan53 · Daderot · Jarekt · UAwiki · Midnightdreary · RaboKarbakian · Spizaetus · Mark Marathon · Stefan Kühn · A ri gi bod · Хомелка · Headlock0225 · Krassotkin · Fayhoo · Elreysintrono · Nyttend · WereSpielChequers · EurekaLott · Teles · SecretName101 · Tangopaso · Notafly · Pyrophyt · FunkMonk · Vuxi · Mariomassone · Ecummenic · Svensson1 · Gamaliel · LlywelynII · Shadowxfox · Paris 16 · Xgeorg · 玄史生 · Иван Дулин · Neelix · Slambo · Jacopo Werther · Holger1959 · Billofocham · Pi.1415926535 · Pitke · ~riley · Iain Bell · Eddaido · Auntof6 · Altona · Josve05a · Howhontanozaz · Rsteen · Saga City · Wheeke · Sebastian Wallroth · Threecharlie · Achim55 · DanTD · Figure19 · Nilfanion · Nizil Shah · Сергей 6662 · Drbones1950 · Tdorante10 · Kzirkel · Djr13 · Xufanc · Xnatedawgx · Palamède · Salicyna · WolfD59 · Kenmayer · Rudolphous · Senapa · Wikimandia · RubeHM · Dankarl · Entertainment Buff · Haplochromis · Pierpao · Oursana · Liné1 · Sanandros · Parma1983 · Io Herodotus · Oaktree b · D-M · Archaeodontosaurus · JoJan · Anniolek · Daphne Lantier · Ham II · Billinghurst · Rodrigolopes · Elkost · Anvilaquarius · Wiki13 · Geogast · PJ Geest · Llann Wé² · Paulbe · AragonChristopherR17Z · FocalPoint · Funandtrvl · Junkyardsparkle · Vincent Steenberg · WaldiWuff · Riozujar · Oxyman · Offnfopt · Howcheng · ZxxZxxZ · Kalbbes · Pierre cb · Yann · Carabus · Richard Avery · Oo91 · LamBoet · Jeblat · Luftschiffhafen · Ambrosia10 · 1Veertje · An Errant Knight · DanielPenfield · CaribDigita · Frank C. Müller · Acabashi · Missvain · Lalupa · Ubcule · Beyond My Ken · Amgauna · Jcb · Carolus · Akinom · Rosario Berganza · Morio · Johnsoniensis · Jos1950 · Stefdn · Kleon3 · Sporti · Avron · Strike Eagle · Hans-Jürgen Hübner · Rilegator · Evrik · Jeangagnon · Moumou82 · Vanbasten 23 · Caseyjonz · BartekChom · Gts-tg · Latemplanza · Hhm8 · Michael.Kramer · Ratzer · Jheald · ديفيد عادل وهبة خليل 2 · ThisGuy87 · Marc-AntoineV · Civa · Asclepias · Rodhullandemu · Leoboudv · Stunteltje · Tony Wills · Badzil · Syrio · Wouterhagens · Johnbod · Velma · Triton · Olybrius · Rob87438 · ŠJů · Jotzet · Bj.schoenmakers · LX · B25es · Elyaqim · Kresspahl · Christian Ferrer · EncycloPetey · Bjh21 · Taketa · DferDaisy · 2003:45:5C47:D201:E1B1:6A52:C698:B44A · Delta 51 · Rosiestep
10+	756	Karelj · Bodhisattwa · Spiessens · Zoupan · RobDuch · Bob Burkhardt · Papergirl · 2003:45:5C47:D201:714C:B941:C643:150B · Leyo · Vvven · Fma12 · Rhadamante · Yzarg · Infrogmation · Xenophon · Tom-L · Djembayz · Dharmadhyaksha · Joseolgon · 2003:45:5C52:501:7DBD:1F06:2A7D:2A2F · Odysseus1479 · Basilicofresco · NiD.29 · Peteforsyth · Ariadacapo · Sailko · Irønie · Olyngo · Tiven2240 · Mirokado · Joanbanjo · Tsaag Valren · Geek3 · Kennethaw88 · Huldra · Pigsonthewing · Blackcat · Daniel0816 · Marcus Cyron · APictche · Te750iv · G.dallorto · Tiberioclaudio99 · Jwh · Tragopogon · Chumwa · Mats01 · Chenspec · LutzBruno · Sgconlaw · W.carter · Pe-Jo · Guanaco · Moreau1 · Look2See1 · Gérald Garitan · No such user · Blue Tulip · Popolon · Catfishmo · Jwillbur · Felspar13 · Scewing · Stolbovsky · Rédacteur Tibet · Hornstrandir1 · Finavon · AndreasPraefcke · Erfil · Fleur-de-farine · Zumalabe · Yakudza · Ratte · Magog the Ogre · OSeveno · T Cells · Afifa Afrin · Voidvector · The real Marcoman · LBM1948 · Mattes · FredD · Salix · Ji-Elle · Garitan · Martijnvans · Markscheider · Hyacinth · Roumpf · Rafic.Mufid · Dick Bos · Mvolz · Armbrust · Racconish · Goldchinese · Freddy2001 · MB-one · Infinite0694 · Mabalu · Jeff G. · Was a bee · Tiefkuehlfan · Totodu74 · Ulf Heinsohn · 2003:45:5C47:D201:6D85:4393:A72:3CE · BeatrixBelibaste · Eurodyne · SunOfErat · MartinB29 · Mercurywoodrose · Chenzw · Kagaoua · Aschroet · Gbawden · Ltshears · ProfessorX · 2003:45:5C47:D201:59E2:8F39:35DA:E38B · Wmpearl · Karmakolle · Lost on Belmont · Crouch, Swale · Gretarsson · 2003:45:5C47:D201:A9CE:A690:2ECD:3C38 · Mhmrodrigues · KaiKemmann · HantsAV · Ras67 · Chaoborus · Ghouston · PBS · Speravir · Renamed user akdllvjbhlnbjfl · GavinLloydBogart · MagicatthemovieS · Rsocol · Sealle · 2003:45:5C3D:FF2B:A5BB:84F4:8128:1281 · Fructibus · Tillman · Ritarisk · Civa61 · Smiley.toerist · Veikk0.ma · PKM · Cayambe · Geo Swan · Als33120 · Artix Kreiger · Amitie 10g · Steve Morgan · A. C. Tatarinov · JASpencer · Alandmanson · Globetrotter19 · Burts · Goudron92 · HugoHelp · Edgar181 · Wolfymoza · Lyokoï · Traumrune · Poyekhali · Amada44 · 2003:45:5C52:501:A916:DEF6:D826:B85A · .js · Ɱ · HLHJ · Alan · Asura2007 · Den man tau · Farragutful · Brunei · Roland zh · Mdd · Torsch · 2003:45:5C52:501:65B4:893F:AFE6:17AA · M2545 · Trankuility · Thierry Caro · 2003:45:5C47:D201:BC13:18E9:18B5:38CE · Jeanhousen · Howard61313 · Zeete · Rachmat04 · Baronnet · Benzoyl · 2003:45:5C6F:C596:D9F0:354C:D10C:BBB7 · Дима Г · Kopiersperre · Countakeshi · Taivo · Keivan.f · Mel22 · 木の枝 · Cookie · Xwejnusgozo · Marcok · Ortadox · Roble-abedul · Cbigorgne · FrankyLeRoutier · Yngvadottir · ShelleyAdams · Achim Raschka · 2003:45:5C47:D201:B5CB:9046:5E92:3C13 · Jarnsax · 2003:45:5C47:D201:A478:3555:F828:F5BF · Nachosan · Underwaterbuffalo · Petebutt · P4K1T0 · Jozefsu · Abujoy · MMFE · RadioKAOS · HaeB · Jean11 · 2003:45:5C47:D201:BDBF:4AF4:75E6:9ACD · Mnnlaxer · 2003:45:5C47:D201:74CF:BE7:4EAA:BC73 · Raimundo Pastor · Hedwig in Washington · 2003:45:5C52:501:8509:F471:C550:4466 · Spinster · Jula2812 · Agriculturist50 · Michael Romanov · Zundark · Verdy p · Vysotsky · Brackenheim · Marco Chemello (BEIC) · 84.122.197.221 · Kulmalukko · 2003:45:5C47:D201:D8DA:FB40:A123:BD90 · Lx 121 · Victuallers · ServB1 · W84jon · Blue Elf · Gary Dee · JotaCartas · ClemRutter · Martin Falbisoner · Lin linao · そらみみ · Marianne Casamance · Utcursch · Witia · Humboldt · 2003:45:5C52:501:1564:BF78:30D:78F3 · Ita140188 · Екатерина Борисова · Stratoswift · Fmvh · Agafoklea · TommyG · 馬面長伊奈 · Leo1pard · 2003:45:5C6F:C53C:1045:7C2F:26D6:DD85 · Stïnger · OM2003 · Eco84 · SimmeD · Artix Kreiger 2 · Veliensis · Cplakidas · Perumalism · Slowking4 · Bryant2000 · Jed · 2003:45:5C47:D201:ED6C:8939:7749:D39C · Alaspada · Paul foord · A. Wagner · 2003:45:5C52:501:AC8E:36E3:5B38:1261 · Andreas Plank · Richardkiwi · LigaDue · Blast furnace chip worker · Rybulo7 · Green Giant · Schlosser67 · Hannolans · MHM55 · Viewdusk · Fadesga · Atamari · Djadjko · Léna · JasonCarswell · Naraht · Illegitimate Barrister · IveGoneAway · Fredlyfish4 · GreenMeansGo · AlvaroMolina · Årvasbåo · CaroleHenson · Anna reg · Northamerica1000 · Lambtron · 2003:45:5C52:501:1015:BAE9:6CB0:DC2E · Nicor · Спасимир · Liverpoolpics · Wdwd · Outriggr · Ibrahim.ID · Catsmeat · Gastón Cuello · Глинистый сланец · 2003:45:5C47:D201:B1F5:5997:9FA8:794 · Motacilla · Keith D · N. Wadid · Davey2010 · Yapparina · Indrajitdas · Gaffeettee · Downtowngal · Drongou · Aloneinthewild · Icarusgeek · Gbarta · 99of9 · Navvvrisk · MassiveEartha · Carlomorino · NoSnakesInIreland · 2003:45:5C52:501:4476:54FC:C4A3:2BB3 · Lewenstein · Aitorembe · Mapmarks · Special Circumstances · Poliocretes · DASonnenfeld · 89.215.207.81 · DragonflySixtyseven · Iranianson · Ms Sarah Welch · 4nn1l2 · Labattblueboy · Rasbak · Totorvdr59 · Seb az86556 · Checkingfax · Pkbwcgs · Levi bernardo · Sint Aldegonde · Edwardx · Shyamal · 2003:45:5C3D:FFBF:1575:2AFA:A511:6F0F · Basvb · Leutha · GO69 · Gras-Ober · Camerafiend · Snek01 · Sneeuwschaap · Simon Peter Hughes · ComputerHotline · Markx121993 · 2003:45:5C52:501:FC00:EF5F:2B2F:4381 · Rec79 · DarwIn · B222 · Fab5669 · AmyNorth · B dash · Liuscomaes · Nickknack00 · Semofa · PhysalusAntiquorum · Eponimm · Mewa767 · Zetpe0202 · Ebrahim · 2003:45:5C3D:FFD8:28FC:E646:82B2:6997 · INS Pirat · Frze · Hydro · AYE R · Waz8 · Sweet kate · Lymantria · Primaler · Mauelhure · Abraham · 2003:45:5C3D:FFFC:F8B7:BC02:DA9C:D698 · Nederlandse Leeuw · DerBorg · Ellin Beltz · Rafael Zink · Cobatfor · J. Patrick Fischer · Ursus · Sjokolade · 2003:45:5C3D:FF68:2420:4B85:5F35:F966 · Michael Bednarek · Timbuk-2 · XXN · Szczureq · MB298 · Vzeebjtf · Codas · Enrique Cordero · Russian Rocky · Jacquesverlaeken · Jospe · Maliepa · Sascha GPD · Hintha · Warairarepano&Guaicaipuro · Guliolopez · AntonierCH · Mhohner · AT44 · Ain92 · 2A02:810D:26BF:D974:BD99:4CB7:E73B:8D6F · Chris.urs-o · CarlosVdeHabsburgo · Lioneldecoster · Arbalete · Trzęsacz · Ecelan · Cosal · Lamberhurst · Fernandezmv · Malcolma · Ле Лой · Kognos · AxeEffect · LookLook36 · RobertLechner · 2015.ww · Lobsterthermidor · Musée Annam · Mazuritz · Horcrux · Chiswick Chap · Goustien · 2003:45:5C52:501:9DC7:FC0A:8B2:4B2 · Thor19 · Carlodell · HarzBuff · Abubiju · Ganímedes · Pechristener · Tromaster · AMHQ · ArjanH · Brian W. Schaller · Macassar · Selso · Monopoly31121993(2) · Meneerke bloem · Thibaut120094 · Grabado · Chief tin cloud · Waldir · Daniel Case · 2003:45:5C52:501:D1A7:5BF7:9272:84EC · Alafarge · Joshbaumgartner · 2003:45:5C52:501:B0F3:3F14:3D6F:9814 · Arpyia · Le Passant · Лобачев Владимир · Roseohioresident · Angelgreat · DeFacto · BSonne · Josuevg · Gonzo.Lubitsch · 2003:45:5C3D:FF44:800C:F751:C684:6DA6 · Blademasterx · Gereon K. · Mx. Granger · Imedeiros · Fenikals · Uleli · Bff · Rakás · Olivier · Mhockey · Xover · Hdamm · Abxbay · Howicus · ThbtGrrd · Tokorokoko · 2003:45:5C6F:C51A:1926:669A:ACD5:959D · Stefan2 · Itti · Mätes II. · AtticTapestry · T Cannes I You · Runner1928 · 2003:45:5C47:D201:CC5F:47A1:6B55:74ED · Mithril · Karldupart · Fiver, der Hellseher · 2003:45:5C52:501:C8DE:E145:4C0D:58EA · Mackensen · 2003:45:5C3D:FFFC:7CDD:E9D6:5097:ECA6 · MausoGalla · Santasa99 · Moheen · Reise Reise · Innotata · Codrinb · Mjrmtg · 2003:45:5C3D:FF24:CCF2:E02C:8B78:DBAE · Jo-Jo Eumerus · Auric · PigeonIP · Kusurija · Martinvl · Alekino · 2003:45:5C52:501:604F:9631:14B8:A53A · Gürbetaler · Mu301 · Sionk · Spinningspark · MisterSynergy · Bukk · Opencooper · 2003:45:5C6F:C515:D92F:4C6F:FB22:86C5 · Djampa · Plucas58 · 2003:CA:DBC5:2A32:7D52:51E9:67C2:D47B · KAVEBEAR · 93.147.192.126 · Freddo · 2003:45:5C6F:A801:D599:637F:9D67:EF31 · Qwfp · IJReid · Baomi · Gryffindor · PicTrans · Brams · 2003:45:5C6F:C54E:89C2:4C44:51E5:9F0E · Arado · Achim Hering · 4ing · GT1976 · ПростоУчастник · Joalbertine · Kritzolina · Mike Cline · NOSSER · Nehrams2020 · 67.101.5.100 · C messier · Kevmin · Goesseln · Бериллий · 2003:45:5C6F:A801:CDA:53C9:3317:F1DE · Markhole · Huntster · AFBorchert · Threeohsix · Berdea · Triedros · DJKinsella · 2003:45:5C52:501:5581:E805:D0FF:990C · Zde · CoffeeEngineer · Ichthyovenator · 2A02:810D:26BF:D974:9568:3B89:9B9F:5A55 · We hope · Antoni Nomen · Srittau · King of Hearts · Dbachmann · Concord · Casigno145 · AVRS · Rekowo · Hobbema · Slimguy · Waggers · Sternrenette · Earflaps · Obi2canibe · Chetvorno · Ellywa · Nadiatalent · Wikibelgiaan · B kimmel · Y-barton · Mhhossein · Gzen92 · FERNANDES Gilbert · 2003:45:5C3D:FF99:7CDD:E9D6:5097:ECA6 · GvozdevN · 2003:45:5C3D:FFCE:1575:2AFA:A511:6F0F · Moon rabbit 365 · Ankry · Nev1 · 2003:45:5C47:D201:85D0:816F:AE76:A4E6 · Joanna Kośmider · Laurent Bélanger · John Tann · 2003:45:5C52:501:4DDC:FC5B:39DF:7B14 · Tamba52 · DnaX · Articseahorse · Marionlad · Wie146 · Lieutcoluseng · Philafrenzy · Cavarrone · Кейра · 2003:45:5C52:501:9DAD:C552:4699:2564 · 2.40.76.58 · Dans · Philmarin · Lomojo · Djkeddie · Anomalocaris · Averater · Brakeet · Bri · Sémhur · Ælfgar · Montanabw · E4024 · Chris Light · Havang(nl) · StellarD · 68.165.77.3 · Sturm · Redtigerxyz · Mrwojo · DenesFeri · AgainErick · 2003:45:5C3D:FFD8:F82C:34C6:8F04:3597 · Tine · Ies · MaxxL · Guise · Pristurus · Chaumot · 2003:45:5C3D:FFBA:8FA:A352:5FE4:C2B4 · WikiNameBaks · Edelseider · Y.haruo · Eugenio Hansen, OFS · RL0919 · Franz Xaver · Roxanna · Hadonos · Sgsg · Cedalyon · Branor · Imoisset · Snowdawg · FierceJake754 · Ballofstring · Dornicke · Chabe01 · Multichill · Xabier · Kerry Raymond · Capricorn4049 · Xiengyod · Chris j wood · TomCatX · Pugilist · CallyMc · Metrónomo · Natuur12 · W!B: · Hellerhoff · Avery Jensen · HyperGaruda · 2003:45:5C52:501:FC5D:1D41:1B46:AD57 · Wlodzimierz · Library Guy · 2003:45:5C77:9B01:C578:2F48:DE54:13C0 · Hispalois · PowerBUL · Myasuda · Palickap · 178.203.234.178 · Doko · Lori-m · FDMS4 · Smallbones · Pablo Busatto · 2003:45:5C3D:FFED:28FC:E646:82B2:6997 · G41rn8 · Patko erika · JPRiley · Ryan Hodnett · NessieVL · Tetris L · Michel Chauvet · Pegasovagante · 2003:45:5C52:501:D44A:DAAF:4A5F:A785 · Zykasaa · JGHowes · Jahobr · Skinsmoke · Sl · Schofför · Ibrahim Husain Meraj · AltSylt · Bungert55 · Gwillhickers · Joan301009 · 2003:45:5C52:501:6463:50E2:DED4:2603 · Drdoht · 67.101.6.143 · Washuotaku · HonorTheIsland · Zyperkux · Xenotron · Lamiot · Phso2 · Kintaro · Jdx · E-Soter · Simon Burchell · Rbianchi96 · MopTop · Niklem · Correlatio · Goodshort · Magicpiano · Daniele Pugliesi · Darekm135 · PePeEfe · Nadkachna · Pratishkhedekar · Varaine · Jllm06 · Crowsus · Jeff the Obscure · KSFT · DilletantiAnonymous · DerekvG · Nv8200pa · Underbar dk · Marco Chemello (WMIT) · Wstrwald · Electron · 2003:45:5C6F:C54E:D18A:D593:5F3D:6FF3 · 2003:45:5C77:9B01:64AA:9A71:5A83:1FFB · Texaner · Art Jarka · FallingGravity · RockyMasum · Ranveig
	2128	André Koehne · Rrburke · MM · Nicola Quirico · 2003:45:5C3D:FFA1:CCF2:E02C:8B78:DBAE · Meinhattan · Magnus Manske · Jameslwoodward · Never covered · Scillystuff · BaldBoris · 2003:45:5C77:9B01:60E0:BA69:8659:BCE1 · 179.7.219.237 · Zunkir · Patafisik · Figugegl · Thurs · Poeticbent · Skyllfully · Bonifácio · Prüm · Retired electrician · Anne-Sophie Ofrim · Hrishikes · IkbenFrank · Greenshed · Msaynevirta · The Earwig · %Pier% · Dre Rock · Gerold Rosenberg · 2003:45:5C52:501:8DFE:EBBA:C378:1356 · Nicola · AssosA · Ser Amantio di Nicolao · Zcarstvnz · Corlup · ゴーヤーズ · 2003:45:5C77:9B01:EDA5:E973:69C6:718F · Clindberg · Tigran Mitr am · Migebert · Tomisti · Meanderingbartender · 2003:45:5C3D:FF65:B1B4:C81E:8CA4:19D2 · EdwardPan · Schekinov Alexey Victorovich · 150.214.94.231 · Caulfield · DCB · Rettinghaus · Jordi · Melchior2006 · 2A02:810D:26BF:D974:800C:23A4:EE99:15A1 · 2A02:810D:26BF:D974:F83E:4E42:C7E7:65AA · Sitacuisses · Чръный человек · SBaker43 · Pufui PcPifpef · Jdsteakley · Objectivesea · Warfieldian · Verbcatcher · 93.219.41.139 · Hyju · Gumruch · Ben P L · Bensin · 73.221.151.143 · Totemkin · Tozina · Kaiketsu · Neddyseagoon · AnonMoos · Rhododendrites · Jacek555 · Vennor · Editør · Btarchiv · Piero~commonswiki · AnRo0002 · Cycn · K'm · PicturePrince · GwenofGwened · Hangsna · Pyb · Tobias ToMar Maier · 2A02:810D:26BF:D974:C18E:48CC:815E:F45E · Docteur Ralph · Mircea · Томасина · AdamBMorgan · Yuriy75 · Holapaco77 · Denverjeffrey · RP88 · Ahecht · El Funcionario · Ykvach · Artaxerxes · Pibwl · Brunokito · Atlasowa · Kboht · Judicieux · Jmx · 2003:45:5C52:501:F4A9:5A45:75AD:F197 · Nerdoguate · Wikiklaas · Schmarrnintelligenz · Nāvika · Faolin42 · Hzh · Trappedinburnley · Rabanus Flavus · Moondyne · Rjdeadly · 153.224.217.124 · Colin Douglas Howell · Place Clichy · StefanTsingtauer · Pivox · JPS68 · Carnildo · Mitternacht90 · Jghdhujrnfbdxfgsjfj · Richard Arthur Norton (1958- ) · Hiart · Mardus · 87.97.128.164 · 2003:45:5C3D:FF68:8FA:A352:5FE4:C2B4 · WikiAnika · Skim · Frenouille · HerrAdams · Superchilum · Strobilomyces · Emeritus · A.Savin · 2003:45:5C6F:C515:D075:82B5:A789:A723 · Sattigrib · Elitre · 2003:45:5C52:501:2DF8:DCC2:D3C9:C4C7 · Stombari7 · Carcharoth · Konto na chwilę · Mandariine · Cimbail · 2003:45:5C52:501:8C44:C5B1:F18E:179D · Einstein2 · Bennylin · Kumkum · Archeologo (Museo Galileo) · Birne1993 · Xth-Floor · Cak22 · Smasongarrison · World's Lamest Critic · 2A02:810D:26BF:D974:69D3:F636:1641:2BD6 · Sadads · Gauss · Lubiesque · Rcbutcher · Koffeeinist · 1630ab · Koumz · Aerosolarium · Mai-Sachme · Underlying lk · Amfeli · ביקורת · Macreanu Iulian · Dyolf77 · Kaldari · Lwarrenwiki · Hohum · 2003:45:5C77:9B01:D82A:72C6:FAA8:E244 · Nightflyer · Stuartyeates · Ariel196 · Joschi71 · EChastain · Tschubby · Pan Tau · Achird · Temdor · Surrey101 · Dldwg · Tortillovsky · BukhariSaeed · Boogie Boy · Esme Shepherd · 2003:45:5C52:501:7079:3B35:552E:41E7 · Tony Webster · Dahn · 2A02:810D:26BF:D974:8855:B95:FEFA:FAE4 · Jan Arkesteijn · Haabet · Giorgio Michele · Karl Gruber · MILEPER · Dreizung · Kayser Ahmad · Kenraiz · Chris06 · Jordiferrer · Hergilei · Histragic · Waltloc · JanB46 · Kgbo · Nessun31 · Taxifaga34 · Kawaart · 2003:45:5C52:501:D823:4809:FA95:A917 · Off-shell · Catatine · Simisa · Francis Schonken · Tar-ba-gan · Jergen · McGeddon · Macesito · Discasto · Gcd822 · Rosty · Kintetsubuffalo · Voice of Clam · 110.164.44.2 · Alexandronikos · Aleator · Cucumber · Graham11 · Karsten11 · Origamiemensch · BhagyaMani · Courcelles · 2A02:810D:26BF:D974:58A5:47AD:4FD7:3ED4 · Grentidez · Inugami-bargho · Marencja · Tisquesusa · 2A02:810D:26BF:D974:F522:BB68:6D3D:AA77 · Jonny84 · Kai3952 · Kubanczyk · 2A02:810D:26BF:D974:D91F:8311:B0C0:9B4A · Peter coxhead · Lionel Allorge · RoRo · Naruo · DAJF · Aubry Gérard · Tscharmaut · 14.207.169.110 · Mike Peel · Sanya3 · ~AntanO4task · Ipoellet · DMacks · NeoRetro · OlEnglish · DimiTalen · Axpde · Quibik · Eleassar · Astirmays · Falk2 · 122.151.185.219 · Dominikmatus · 5snake5 · Preto(m) · Jonathan Cardy · Zeromonk · Fridolin freudenfett · Atomojvi · 2A02:810D:26BF:D974:FC82:993C:35A4:6F44 · Daniel Mietchen · JohnSka · Saftgurka · Hazmat2 · Lotse · Iloilo Wanderer · Jacek Halicki · Ketil3 · Alpsdake · Dmitry G · Donan.raven · Seudo · Cladeal832 · Aspargos · Darekk2 · Gikü · Sendelbach · 80.6.235.179 · Aymatth2 · Storye book · 88.69.88.161 · Soldier of Wasteland · Philippesalv · Lineagegeek · Villanueva · Transifex · Mjroots · Benji the Pen · Accurimbono · Banfield · Mr. Matté · Lantus · Kareyac · Demidenko · Elya · Peter Greenberg · Epìdosis · Francesco Braia di Corradi · Lamashtu2006 · Mateussf · Kleeblatt187 · G S Palmer · 2003:45:5C3D:FF2B:B1B4:C81E:8CA4:19D2 · 93.36.41.6 · Leonid · Czar · Druschba 4 · ברוך שם · Tschips · R'n'B · ArteGod · 203.26.122.8 · Brainy J · CEP · PRUSS · Another Believer · Cnbrb · Ixocactus · 179.7.211.218 · Ekenaes · Akme · Burzuchius · Donarreiskoffer · Yodaspirine · Upstatepolyglot · SNAAAAKE!! · 83.55.78.200 · Cpt.a.haddock · RhinoMind · Aṭlas · Eunostos · Kaganer · Niera · M5 · Nick · Mywiz · Pitpisit · DACC23 · Chyah · PawełMM · Wereldburger758 · Halibutt · J.-H. Janßen · Tremendo · Stas1995 · Earwig · Fabartus · Adam37 · A1AA1A · Jianhui67 · Pa3ems · Xavier Dengra · EUvin · 2003:45:5C6F:1201:FD2C:4791:A31:1114 · Michael32710 · 2003:45:5C6F:C59D:9C2A:B500:470D:A08F · Futurewiki · Haendelfan · Capankajsmilyo · Arjuno3 · Omni Flames · Rosarinagazo · Batfan1966 · Anna Frodesiak · Jacqke · 1989 · Cyborian · Dorieo · Felipe da Fonseca · Dim Grits · KDS4444 · Rémih · Wiki-uk · Buch-t · Black Morgan · Desyman · ArthurMcGill · Zarateman · Solomon203 · Robin Chubret · Mr Ricochet · 2A02A03F · Spyder Monkey · Torana · Gunkarta · Julian Felsenburgh · 2800:200:E850:F83E:7430:6F46:65D6:3241 · Triplecaña · BrillLyle · Reinhard Kraasch · Panek · Engelberthumperdink · Famartin · Stilfehler · 108.230.184.59 · Orienteerix · Benoît Prieur · Vogler · Marekm246 · 2003:45:5C52:501:48FF:FD3E:F526:4954 · Bossanoven · Tyssul · Mef.ellingen · Ivanhercaz · XalD · Doug Coldwell · WPSamson · Asurnipal · Clpo13 · Shev123 · Richard Nevell · WikiWookie · ZojaZoja23 · Rosenfeld~cswiki · Atwngirl · Ellicrum · Ira Leviton · Davidng913 · KeFe · Milowent · Raphael Figueira · Sarang · Kmoksy · 2A02:810D:26BF:D974:7DF6:B21:2B20:EA84 · Jcfidy · Hydrargyrum · BevinKacon · Wikiwal · 2A02:810D:FC0:794:544C:5E61:BDA3:9681 · Trougnouf · 125.24.109.63 · Dcapillae · Insider · Peter Flass · Mitte27 · FakirNL · 87.0.97.51 · Mjbooher · Poulpy · El Grafo · MNXANL · VileGecko · Brühl · Manma2917 · 2A02:810D:26BF:D974:49D5:A091:CDB8:C0F7 · Evil berry · علاء · Tim1965 · Paperoastro · Juicebable · Ancalagon · Alexis Jazz · 104.243.160.6 · Denniss · Romaine · O0TsRVi7 · 80.136.88.211 · Rocky Wyngaard · Blaue Max · Mariordo · Rosenzweig · Frangern · Der-Wir-Ing · Blairall · Kirtap · 2001:7D0:828B:A580:5DE4:BDD1:7B48:F2FB · Yodin · AlbanGeller · Umimmak · Ksn.kenny · Thcollet · Green Mostaza · Hubi47 · Lidewij C J. · MiguelAlanCS · Giaccai · Carl Ha · 89.204.137.69 · Minoo · 2A02:810D:26BF:D974:DCF1:89FC:A408:B417 · Pelikana · Llywelyn2000 · SchiDD · Silverfish · Oscar . · Rolf H. · Simplificationalizer · 2A02:810D:26BF:D974:7975:99CD:C9D1:DADA · Alians PL · Yerevantsi · DAAyanz · 8-hachiro · MiPe · Peter17 · Calliopejen1 · Julien1978 · Epicwolfman · B2Belgium · LudwigSebastianMicheler · Generic1139 · Heralder · Daehan · Bảo Ngậu · Waterborough · 93.36.67.238 · مصعب · Hartmann1948 · Itu · Camulogene77 · Henristosch · Szczebrzeszynski · HerkusMonte · Грищук ЮН · 2003:45:5C52:501:A033:7669:5111:7A34 · Savvyjack23 · WhiteBook · Knöre · 2003:45:5C77:9B01:A1C9:79B8:9355:10CD · Shisma · Krokodyl · Meissen · 93.36.60.40 · Eweht · Dwergenpaartje · Bildfinder · F4fluids · Luan · Alexpl · Odysses · Wolfman12405 · L'amateur d'aéroplanes · Jkadavoor · Mathmitch7 · Pixel8tor · Muhranoff · ProfReader · Touzrimounir · ACBahn · Gandvik · Mdeazpeitia · Shawn in Montreal · 1970gemini · Christian Imboden · 2A02:810D:26BF:D974:C834:6139:5665:CCF6 · Erlenmeyer · Filo gèn' · עדירל · NMaia · Eymery · Julien Demade · Dave.Dunford · 72.69.85.195 · Giogo · Timmaexx · Tajotep · Kigsz · FMMMC · LittleWink · Leoclerc · Jack ma · Ismoon · Chrischerf · Antonio Mette · Rupert Clayton · Schuppi · Nicholas Gemini · YvoBentele · 2A02:810D:26BF:D974:80FE:F464:75CE:7D9E · Bidgee · Gampe · Bubba73 · Ymblanter · Crazypaco · Quoique · 67.101.6.148 · יעקב · Andrybak · Алексей Гоманков · Sevela.p · Bakelith · Vsop.de · Sudzuki Erina · 67.101.5.231 · Hektor · Cameron Kay · 2A02:810D:26BF:D974:E80D:FAC1:E3C5:C06 · O484 · Mikael Häggström · Morn · Tommy Kronkvist · Durdet · Spem Reduxit · Torsade de Pointes · Epicgenius · Asybaris01 · Eriksw · Ankax Hayastan · Bestiasonica · Marrovi · Gorthian · Trigueiro martins · Stewi101015 · Kosovoworld · Manwełw · Urdangaray · 2A02:810D:26BF:D974:48E4:912A:6242:C7 · Sbmeirow · Tanktopbra · Manuelarosi · PatHadley · Tikky19 · Htm · Szilas · Abc10 · PearlieGirl · Cobalt~frwiki · 84.141.23.119 · 207.255.21.120 · FDRMRZUSA · Kri · 庚寅五月 · RedWolf · Schiwago · Usamasaad · Rich jj · Hungchaka · Motopark · 93.44.108.184 · BurritoBazooka · Catrìona · Explicit · Love Krittaya · Dsprc · Sprachpfleger · SpanishSnake · 2A02:810D:26BF:D974:5C8F:9B98:C189:6BF0 · 221.144.249.236 · Philippe rogez · Selbymay · Alphabeta · Lämpel · My-wiki-photos · Gaius Cornelius · Oncken · Melibokus · Velocipedus · 204.147.202.108 · Finoskov · Alter Fritz · Uwca · Briarfallen · Applodion · Erik den yngre · Alistair1978 · LodA · 掬茶 · Kinori · 2A02:810D:26BF:D974:1158:3BE9:4D53:BB3 · Chicbyaccident · Tyler de Noche · Patrice78500 · Tanzmariechen · Ahalyamandana · Keith-264 · Rzuwig · Mliu92 · Sheila1988 · Adavyd · Ra'ike · 85.176.2.139 · SovalValtos · Capmo · Ermanon · Drdpw · Pere prlpz · 6PO · Mordomo · Jacques Ballieu · Ldhank · Peacedance · Ronev · Iudexvivorum · JordiCuber · Juan Villalobos · Jpcuvelier · Zabia · Thib Phil · Tiraden · Jim Derby · QuartierLatin1968 · Watchduck · Mac9 · Tom elm · Dinoguy2 · Sigbert · J budissin · 5.199.182.203 · Nomoonman · Florival fr · Vcohen · Asarlaí · Georg Pik · LBE · Kleinzach · عبد المؤمن · Hannibal · 27.204.203.32 · Raupkopie · Sammyday · NeoGeneric · Protestant · Toni Pecoraro · 2800:200:E850:F83E:E59E:D293:DD61:4C4C · Sinuhe20 · Emha · Professor. Stemsom · 三猎 · Ekabhishek · Bijay chaurasia · SMcCandlish · Frodar · Taxelson · Herr Satz · 2.110.54.193 · JarrahTree · Marsupium · Jajabis · Laddo · Libby norman · Villy Fink Isaksen · Gwalstawd · 67.78.226.238 · Jonyy008 · KurodaSho · Chalupa · Paul venter · Moralist · ZemplinTemplar · Jhw57 · Thkgk · Herranderssvensson · 2003:45:5C3B:BC01:78CB:9C9B:C9DF:10E5 · Jaqen · Signo · Mmcannis · 89.158.45.114 · Brya · Cygnis insignis · Afnecors · Grasso Luigi · Dinkum · Comhachag-bheag · DeWikiMan · Caravaggista · Aetherophon · 2A02:810D:26BF:D974:C9E2:9164:A73F:A578 · DavidAHull · 185.22.142.156 · Grunpfnul · Drown Soda · 67.101.6.216 · Лорд Бъмбъри · Timothy Titus · Martin Sg. · 2A02:810D:FC0:794:BC49:23A5:D21B:EAB5 · Kugel~commonswiki · Corker1 · Arr4 · 2800:200:E850:F83E:E826:EFF3:2ACB:3050 · Artur Andrzej · 79.47.229.166 · MGA73 · Basquetteur · Flinten-Uschi · AnonNep · Mcapdevila · Cymbella · Lykos · ValeriySh · 5.50.126.192 · 103.224.129.19 · Gderrin · Марина Рихтер · Justin.A.Wilcox · Funke · Zenith4237 · Riesengrey · Berthe · Manudouz · DanielleJWiki · Dormskirk · Jarash · Richard Coté · Extrapolaris · Didym · Glasshouse · Varavour · SKas · Cliftonian · Palosirkka · Bardenoki · Aavitus · Richard Nevell (WMUK) · N8eule78 · Opabinia regalis · 211.14.206.48 · Jopparn · Soerfm · 104.243.162.234 · XRay · 5.228.251.75 · Jaquento · FredrikT · William Ellison · Elkágyé · Hilty7 · SylviaStanley · Ich · ChemNerd · גלוריה ללויה · Michał Sobkowski · Fitzcarmalan · Mikani · Bloopersstv · Terriffic Dunker Guy · Fuaran buidhe · 2A02:810D:26BF:D974:510A:1B9F:97B2:C772 · WhisperToMe · 86.183.27.11 · Very trivial · Caftaric · Aeroid · Юровский Александр · Vesta · TowardsTheLight · Niridya · Fausta Samaritani · Pavouk · BASA Спасимир · John fitzburn · ԱշոտՏՆՂ · OTFW · M0tty · Chartep · 60.230.204.254 · JonnyNord · 77.112.34.89 · Monsieur fix · HShannon · Kospo75 · Shattered Gnome · 70.51.203.56 · 104.243.165.19 · Magnus J · Bigfan · 78.18.91.209 · Illuyanka · Talskiddy · Engeser · Gliu · Migrant · Zolo · JaS · Mr.Nostalgic · Unserefahne · Urhixidur · 2A02:810D:26BF:D974:C1B1:560F:E3B9:E290 · Ditch Witch · National Names 2000 · Beleg Tâl · Tony Rotondas · 2003:45:5C52:501:94F0:EE5D:6E33:AADF · Chase me ladies, I'm the Cavalry · Alexrk2 · David Levy · Nedrutland · Vanworden · Samwalton9 · Cobija · Rauschenderbach · CFynn · 95.86.78.62 · Peter in s · Fgrosshans · Samwilson · Robertk9410 · Swpb · Мельников · 桂鷺淵 · Charlesjsharp · HB-JOH · Lklundin · Thatonewikiguy · Ecthelion3 · Parsecboy · Mehlaugerst · David Beneš · PatbackT · Zenwort · Marco Frengo · Kallewirsch · 62.107.218.102 · TintoMeches · Joehawkins · 109.149.30.150 · Paleocolour · Felis domestica · 79.97.226.247 · BRUTE · Ajmcbarreto · Mario1952 · Padudarrific · Pru.mitchell · 178.76.188.143 · 50.5.90.177 · StAnselm · Bbruno · Widgia · Ahmadyasmin · Kmhkmh · Deansfa · 月下薄氷 · Rupert Pupkin · Drüfft · William C. Minor · How come why not · Qurren · Outlier59 · Thuresson · Fernando.tassone · Tyler ser Noche · VladXe · Baztwin · Cmuelle8 · Reinhardhauke · Sfs90 · Lone Wolfs · Dencey · Super Dromaeosaurus · AlasdairW · Bahnfrend · HenkvD · Eyesnore · 2001:569:7AE8:F000:893F:CFF2:57F3:C60 · HHill · MikSed · Perhelion · АлександрЛаптев · Dlsnider · Janezdrilc · Pharos · FLAVIVSAETIVS · Seyner · Etienne M · Et0048 · 198.84.253.202 · 79.148.173.49 · Shlong56 · Geof Sheppard · 75.143.245.211 · IppolitoN · Mini.fb · 2A02:810D:26BF:D974:5093:127D:C5A5:17AB · Daviidos · כביסת השכן · 89.215.201.81 · Stang · SDriskell · Ytoyoda · Blythwood · 77.164.133.132 · François GOGLINS · XyKyWyKy · 192.222.180.77 · 82.50.38.71 · Sfan00 IMG · Pippobuono · Usien6 · מנחם.אל · NAC · Benjah-bmm27 · Jossi2 · Barabbas1312 · Helen Purdy · V. Turchaninov · TCY · Casual Builder · Alice2Alice · Domdomegg · 68.165.77.10 · Groupsixty · 2%ɐ · SchroCat · CreiterAdam45z · Crusier · УмныйПёс · Nemo bis · G-13114 · 68.165.77.198 · Samowarat · Convallaria majalis · Mxn · Worldantiques · 86.182.6.145 · AHert · Jon Kolbert · Waitabout · Turris Davidica · 2003:45:5C47:D201:3C2F:A654:8A7:9667 · Azazello&margherita · 86.181.74.228 · Anarchyte · 89.215.205.98 · Pasicles · 2001:7D0:828B:A580:A82A:5706:E5DF:231C · VIGNERON · Qypchak · MagentaGreen · 72.193.238.199 · Cephas · Omondi · Grifomaniacs · Sarah Layton · Salsero35 · Autom · Ponypal918 · Regiomontanus · Labintatlo · TED · Storkk · Lockley · Mark Schierbecker · Pleclown · Cléééston · 24.11.170.191 · Ritagaupp · Agaath · Thgoiter · Gerardgiraud · Parigot · Dadadata · 2.83.106.13 · Aristeas · Jwilkes73 · Asturio Cantabrio · Молли · Zew99 · 81.83.3.56 · Luz Maria Silva · Grueslayer · 5.81.165.84 · Nova · Warley Felipe C.S. · Αππο · Kontrollstellekundl · 178.10.15.141 · Runner1616 · 69.62.189.111 · Siren-Com · Railwayfan2005 · Platte · Pratyk321 · 217.73.23.2 · W like wiki · Queryzo · Vahram Mekhitarian · Павел Баранов · Hariboneagle927 · Zacharie Grossen · Mr. Fulano · Derbrauni · Frieze · 82.113.99.113 · Furfur · Mongolo1984 · WeHaKa · Maclemo · Fahadtayyab · Dunkleosteus77 · Yupik · Vitalfranz · 99.234.209.208 · Aegoceras · PANDA 81 · Isidre blanc · Qoan · Katharinaiv · 2800:200:E850:F83E:D519:A34:4C90:46C7 · Khruner · Lliura · Wars · Copydays · Alienautic · Varnent · Mo2010 · Andreas Schwarzkopf · Tyfalc · 82.26.142.160 · Voxii · Bernd Schwabe in Hannover · Sunstar1223 · Arb · Ssriram mt · Antony-22 · 2804:14D:4CD0:1689:652C:EA85:90D4:5A56 · 24.69.55.221 · 68.165.77.216 · Zieben007 · Alonso de Mendoza · JMiall · The Empire of History · FredTC · Palnatoke · Obsidian Soul · 126.255.72.159 · Vivek Sarje · Cbyd · Tucvbif · Störfix · Robert.Allen · 124.84.14.170 · जैन · Herrinsa · 96.44.178.205 · Andyrivera1 · Savidan · Declangi · Vstempel · 91.116.197.236 · WeeJeeVee · Aroche · Khu'hamgaba Kitap · HorstKMahler · 39.90.169.19 · OktaRama2010 · PhiLiP · Lichinga · Kvng · Hsarrazin · Voyager · Falcorian · Grand-Duc · Gamma 124 · EEng · Ailura · 86.169.238.133 · Marthacustis · Etrusko25 · BunBun-J · Arnie97 · Menikure · RA0808 · Knochen · Apocheir · Wargaz · FAM1885 · 87.8.55.99 · Steven Walling · Arlo Barnes · 2A02:810D:26BF:D974:C866:E639:45EE:9966 · Renato de carvalho ferreira · Tokfo · Derdadort · B1mbo · Marica Massaro · Anka Friedrich · LUSportsFan · Meisam · Fry1989 · Soleincitta · Dino · Artoria2e5 · Mary Mark Ockerbloom · MathieuMD · Ammodramus · SuicideSociety · Micromesistius · Franciscosp2 · Billmckern · Nobita931 · Wuyouyuan · Rebecca Bird · Xoxua · Hallel · PAvdK · FordPrefect42 · 93.133.186.36 · Symposiarch · Thomon · GeeTeeBee · Aabdullayev851 · 86.169.238.195 · 2601:1C2:302:E4F2:9121:598F:B33F:10DF · Tokumeigakarinoaoshima · Dguendel · Ray Garraty · 104.243.160.107 · Voltteri · Zenzizenzizenzic · 92.140.21.144 · 2607:EA00:103:4802:0:0:0:21 · XenonX3 · Jl FilpoC · Annapannar · Hectonichus · 86.167.193.207 · Thibauld Enfroy · PontiusMeropius · ESM · ArnoldBetten · 80.136.69.228 · 150.214.90.47 · Dr. Blofeld · Apalsola · Jokulhlaup · EternamenteAprendiz · Captain Nemo · VVVCFFrance · Rubin16 · 101.108.0.144 · Hydriz · BronHiggs · M G Tuffen · Hans G. Oberlack · 86.180.246.183 · Scolaire · Zello · Heironymous Rowe · Wvdp · Asarelah · Billhpike · Isquen · 167.56.102.30 · Rupert loup · Condor3d · Hystrix · 65.51.91.6 · יבריב · 109.64.83.111 · Philostorgius · Koavf · Juliancolton · Gazebo · 1-1111 · Jfvoll · 188.238.71.52 · 146.198.38.129 · Arbor to SJ · 104.243.172.230 · Chixoy · Leaflet · Rexcornot · 112.239.23.48 · Orest2000 · 86.173.239.113 · 109.34.7.232 · Gkml · Rowley · Casliber · 2A02:810D:26BF:D974:8560:A771:D508:3D6A · Zcebeci · Ninjastrikers · 112.239.115.113 · Inc · Belfer00 · 142.114.111.209 · 71.170.209.30 · 93.185.26.242 · MJWelsh · Simonxag · Schlachtermeister Fock · Summerdrought · Broenberr · 67.100.127.205 · 2A02:810D:26BF:D974:3CA7:91EB:199C:8E01 · 103.224.129.123 · LYALLPURIYAANA · Rukban · Tisanophile · 2607:FB90:2427:3A1C:7517:35AD:98F0:E702 · Mr.Rosewater · Abu Shawka · Smaha2109 · GeoTrinity · 82.50.83.15 · Maxinvestigator · Xocolatl · Eschenmoser · Josef Moser · 73.131.123.81 · Juenti el toju · 89.215.204.84 · HReuter · AlohaKavebear · 松茸取りの翁 · Incnis Mrsi · 87.97.132.250 · 84.114.237.81 · El Dirko · BluesyPete · Dysmorodrepanis · Sreejithk2000 · The wub · Sodacan · Robby · Neworsy · Jahsensie · 67.100.127.218 · Lee M · 37.248.57.187 · Shouriki · Fortunate4now · Monumenteer2014 · PeterCollins · 104.7.20.68 · Adh30 · Ein Dahmer · Technovajra · 160.39.248.151 · 2003:45:5C6F:A801:C9A1:5523:D4A1:992E · 72.82.48.122 · Riverobserver · 80.136.70.13 · Batje · Togabi · שמי סמעון · Vetranio · 63.143.116.0 · PericlesofAthens · Morinae · 114.149.98.135 · PODZO DI BORGO · 187.10.136.72 · Saectar · CherchezLaFemme · Culex · Exroader · Aristoi · Chrissymad · 80.216.247.122 · Respondo · The Claw · Lûgnûg · Geoleplubo · Jgui · Sokoljan · Meister und Margarita · Opzwartbeek · 119.160.102.222 · Tulchan · 豊葦原瑞穂 · OlafJanssen · Broutille · FieldMarine · Vanleiyeur556 · Ppntori · Olivier LPB · PosoniumAster · Urbourbo · T. Anthony · Jamiri · 86.181.74.154 · Jura1 · MichaelFrey · Ingarix · 87.97.130.72 · Aliman5040 · GiMa38 · Piotrus · 77.172.129.218 · ACo2c · 2607:FEA8:559F:DAAD:2CF9:B60F:211B:807E · Joanmrl · 109.145.81.187 · Czeva · Rocknrollmancer · 2607:FB90:A43B:D201:0:1:48CE:FD01 · יושב קם · Catrin · Cudo29 · SounderBruce · Londonjackbooks · Brian Crawford · Nevit · 2405:4800:2C5E:B15E:C561:11B2:BCD6:FAC8 · Svetlov Artem · Kalki · Ruslik0 · Stombari2 · Lupi82 · 渭水生 · آرمین · Babydoll9799 · 2A02:908:1A0:DD40:DCA2:7669:39FC:A9BF · GFreihalter · KMJKWhite · MOSSOT · Maculosae tegmine lyncis · TeleD · Davidzdh · 2A02:810D:26BF:D974:98A0:7BCC:E180:B557 · Crimea · Mccapra · Reda benkhadra · 217.152.56.227 · 58.186.97.62 · F. Riedelio · 2A01:CB08:7EE:9C00:2D7F:EE37:AC16:91A2 · Woodie Wood · Joxemai · 47.61.31.82 · Pietro · 124.132.155.215 · 2A02:810D:26BF:D974:90BB:4BBF:6AAD:DB69 · 2A02:810D:26BF:D974:9C94:D258:3AB6:E3AA · Plani · Prismo345 · 109.149.30.235 · 119.160.116.201 · Born2bgratis · DrKay · Axxter99 · Keegan · Gveret Tered · 87.97.134.212 · Kof1115 · 143.126.203.251 · 80.136.66.200 · Felecita · 95.236.49.239 · Nurg · Centenier · A876 · Wer?Du?! · AGEN143 · Throwawayloiuy · 86.180.244.110 · 209.150.48.244 · Felix Neumann · 78.229.62.188 · Min Bästa Vän · WikiPedant · An-d · Petter Bøckman · Siebenschläferchen · ささら · Castelobranco · Ciacho5 · Jeblad · Michael w · Langenbergstefan · David Eppstein · Cordless Larry · 86.140.217.125 · Litlok · Pbsouthwood · 2602:306:CE6B:83B0:D868:D774:E405:CDE3 · 23.122.100.170 · Basilou · Stephane8888 · Andrew Dalby · 47.34.29.229 · Piki-photow · Zac Allan · 185.120.124.35 · Dicklyon · SaltySemanticSchmuck · Takashi kurita · Albinfo · 86.183.27.42 · Egel · 86.180.247.211 · Putnik · Wheldon Boddy · Dirtsc · Alberth2 · AndrasSkot · Yarl · Doc Taxon · Sixflashphoto · 27.34.20.246 · 199.7.156.143 · 89.217.100.117 · PhilipTerryGraham · GHomowmi · Angkotpadang · Ram-Man · Syuen15 · HeinrichStuerzl · InfoDataMonger · 89.215.204.7 · Hans Erren · 1rhb · Zigzig20s · 86.136.144.66 · Βατο · Hike395 · 2A02:810D:FC0:794:FDC3:6471:4A43:CB0D · LIONEL76 · Bornloser07 · 79.37.201.235 · 220.137.12.105 · P.g.champion · Ohmyerica · Pakeha · 141.84.65.170 · Golpeador · CondeDeBuenosAires · Enstropia · NeoNeo15 · Uamaol · Cindy Bonawitz · 105.230.192.21 · A.j.roberts · Marv1N · Tonton Bernardo · Davide Denti (OBC) · Optimisese · Romainbehar · 89.215.207.196 · Fylbecatulous · 2600:387:5:803:0:0:0:97 · Michel Marpert · 2001:984:20BB:1:A5A4:9CEB:D998:16F1 · 47.59.237.125 · Txitxo1 · 208.54.70.162 · 2800:200:E850:F83E:A506:5AC2:8650:74AB · CecilF · 2A02:810D:26BF:D974:2860:ECA4:6F5C:5F7A · Talmoryair · Uiyugr · Jessamyn · 93.147.198.219 · 178.238.175.129 · Grendill · Udimu · 199.119.232.212 · Phonet · Matěj Orlický · 205.211.133.128 · Dispenser · Marian Spychalski · 2A02:810D:FC0:794:49BF:284A:C942:27AF · Coyote III · Lodonk · Quisqualis · Harlock81 · Larryv · Atupelpmisanuyos · Linguisticgeek · Zusasa · Glunggenbauer · Crisco 1492 · Jebulon · Meisterbochum · Barbara (WVS) · H-stt · 87.97.133.75 · AutomobilePassion · Gunbirddriver · Alex omen · Lindsay658 · 188.74.64.210 · Århus · 105.67.4.34 · 62.201.23.194 · 2A02:8108:13C0:55B:E5FB:502C:CA3D:64CD · Spedona · PaleoGeekSquared · Toto-tarou · AchileTa · Ldorfman · Attis · Stokeyoxey · DavidAnstiss · DerFussi · Epsilon Tauri · Vyacheslav Bukharov · 162.245.81.185 · Dquai · Warp3 · Rjn wiki · Adamdaley · Hillsgrove4L · Juandev · GRuban · 2A01:6500:A044:9A37:E0E3:6445:4600:F83F · Maulucioni · Cloverleaf II · 121.45.79.32 · Tourainehistoria · Messir · JustSomePics · Il piccione zoppo · Mewtow · Cristiano Tomás · Oksmith · KenBailey · Gm King · West32 · 193.134.194.70 · Hannes 24 · 179.7.209.206 · 31.1.24.78 · TigH · Iazyges · 68.165.77.118 · Neuraxıs · Soteria place · ArmouredCyborg · Hjart · Teoamez · Kingsif · 93.185.26.137 · John Jones · Classiccardinal · Klipe · Philg88 · Melot001 · Hameryko · محمد عصام · Akuchling · Che12Guevara · Kablammo · Oimabe · Sir Gawain · Testus · RimerMoshe · 148.88.244.81 · 83.50.136.71 · Batholith · Goldscholars · 195.23.59.233 · 46.121.158.31 · Manni5 · Kergeo · Spielvogel · Renardo la vulpo · 86.173.239.218 · The RedBurn · AnhaltER1960 · LeZibou · GTHO · Dr.Mabuse99 · 86.173.236.124 · 89.75.137.122 · Dreamyshade · Preacher lad · Christian Pirkl · 87.8.134.111 · CaptainHaddock · Gauri · Benreis · JabaquaraSP00 · Austriantraveler · Alturand · Citron · PjotrMahh1 · Hantsheroes · Kddidit · N.Português · Skimel · Zoeperkoe · पाटलिपुत्र · Starkinmn · Arachn0 · Anaxibia · Ineuw · Diannaa · 86.169.239.34 · Rayaraya · Loracco · MainFrame · Deborahjay · Rillke · Joachim Beyenbach · Lucyin · Vriullop · Krazytea · Mgiganteus1 · Djiboun · Arnaud 25 · TFerenczy · 79.82.242.137 · James Allison · Okernick · Jamesluckard · Josef Plch · Orca2014 · Slzemke · Ssbohio · Micheletb · Oop · Miguelrangeljr · Fraf · OldLion · Kjetil r · Jcornelius · Hanay · 199.168.151.173 · 178.238.175.119 · Luisalvaz · Jedudedek · LukeWiller · Lingzhi · Kober · Alamdanishnepali · Justlettersandnumbers · Miguel raul · Gerardolagunes · Jakubkaja · Esculapio · Hobe · Millars · Fritzmann2002 · 2A02:810D:26BF:D974:EDF4:7587:3357:9256 · Otherlugzaw · MWAK · Succu · 93.134.247.151 · 2A02:810D:26BF:D974:54DE:87B7:338D:BCC9 · Okki · Mikemoral · Kryp · Pmj · Rextron · Sardaka · Pacostein · Dogad75 · SteveMcCluskey · Pemilligan · Naersjoen · Franz Rothenbacher · Warrenjs1 · Marimarina · Wtshymanski · Herodotptlomeu · MAx 92 · WhatamIdoing · KTo288 · OSX · 92.1.30.145 · Rochelimit · Grüninger · Adam majewski · 189.217.122.41 · 79.214er · Pko · 151.73.3.206 · Den1980- · Frankemann · 122.108.141.214 · Ndalyrose · 2.32.187.243 · Jamc2 · 50.5.88.62 · Alarob · Pymouss · Thryduulf · 2602:306:CEEE:9220:F9AF:7A77:414B:F205 · Pinomazoza · Martigri · 179.7.221.184 · Tobias b köhler · Bouchecl · Teemeah · Web SourceContent · Bilpen · Pavlo.Pol. · Bibliographies-BreakfastOfChampions · 88.167.60.194 · 131.191.90.126 · Der Buckesfelder · IagoQnsi · Mickey Mystique · Videographing · Hemmans · Slaunger · B.Hort · 59.86.114.8 · Джозеф Галдор · Lijealso · OSX II · Jackson Cordeiro Brilhador · Berita · Estopedist1 · Giunea · NASIMASEM · 117Avenue · Rachid ilctro · Caballero1967 · ManfredK · Ryhanen · Eulenspiegel1 · Lucius Castus · Knuth · Luigi62 · Chmee2 · 89.215.202.58 · Olnnu · Jusjih · Xhienne · 2A02:810D:26BF:D974:8C63:DC36:54:A02A · Archeologo (Fondazione Mansutti) · Kjerish · Puik · 104.243.165.216 · 2A02:810D:FC0:794:6007:83CF:3AB4:34F · Liza2017 · Thomson200 · WOSlinker · Edfyr · FrAnneser · 87.5.4.211 · A1000 · Père Igor · 92.19.186.220 · Jean-Jacques Georges · Balabinrm · Pols12 · Ggpauly · 92.152.83.182 · Dr-Victor-von-Doom · Aldebaran · 68.32.154.213 · Amitchell125 · Be..anyone · 104.243.165.53 · Kelly · Aflafla1 · Hudso2012 · Gzdavidwong · BrugesFR · Hirni58 · CoCoCounty97 · Markdask · Ymnes · SamX · Moebiusuibeom-en · Liji6085 · ZellmerLP · 86.158.174.130 · NehalDaveND · 2A02:810D:26BF:D974:59F4:88E2:A8FD:93BF · Radiojunkie · Ruigeroeland · 82.132.184.22 · Federigo Federighi · LittleT889 · Winnetou14 · 93.73.36.17 · 2405:4800:12FE:BCD8:E0DC:AAD6:A6:3F0B · M11rtinb · باسم · Wittylama · Wikifreund · Gapfall · Cmachca · Ephraim33 · Pitxiquin · Fugitron · 2601:283:C200:4D00:38E7:FB19:F362:2E32 · Senator2029 · Tvcccp · Rhytddphs · 168.69.254.249 · Eccekevin · Yusuf 506 · JElder (WMF) · Gerd Fahrenhorst · 80.136.70.205 · 86.183.18.74 · 84.141.27.65 · 瑞丽江的河水 · 77.231.245.75 · Prosfilaes · Stok · Sandstein · Xiengyod~commonswiki · 104.57.16.192 · Marvinthefish · Lospagna · 83.100.174.82 · Purzelbier · Epipelagic · StarDeg · Moreau.henri · Ophelia Bogner · 130.64.34.197 · Mtsmallwood · DEMOxDAVIS · 144.82.8.11 · WWasser · Balancing Act · LeGabrie · ThomasPusch · 104.243.166.168 · GentryGraves · Ortisa · MeegsC · M. Adiputra · Churchh · Loursin · Moataz1997 · Level C · Dojn pr · Gamsbart · Anaxial · Kippelboy · Toter Alter Mann · Sheriff der Herzen · BaomoVW · 155.95.90.245 · Killian441 · United States of Russia · George Nympton · 2A02:810D:26BF:D974:6824:5C58:6845:F7A2 · Weft · Jax MN · Kaidor · Z440Xeon · Drbogdan · ΖῷονΠολιτικόν · 83.204.164.193 · Zaqarbal · 217.93.156.167 · DCKH · Meister · RickMorais · Franclin 6 · Krypton Commando · Jonkerz · Vmenkov · Prokaryotes · 200.113.234.60 · Aquiles jr · 1971markus · Emeric Géry · 86.183.83.13 · Petermichaelgenner · Marcos D. Reina · 2A02:810D:26BF:D974:2082:5388:35AB:9B72 · O.Taris · 93.185.30.72 · Kong of Lasers · Yoninah · 195.150.188.12 · محک · Informationswiedergutmachung · 92.2.76.8 · Hannah Davis · Seilvorbau · Runologe · Discanto · Artlejandra · 2607:FB90:25B9:7E15:B8EA:97D8:7E19:4293 · Siga · Rlbberlin · MistressData · 122.52.145.188 · Bagas Chrisara · Connor7617 · 72.36.1.26 · RomanDeckert · ThayneT · Merkið · 112.239.115.40 · Categorizing · N509FZ · 93.44.96.184 · Jann · 2.40.79.140 · Pimbrils · Fontema · 86.181.75.5 · Bazi · Privat-User · Ingolfson · Szajci · January · 109.145.87.207 · Роман Курносенко · Jérémy-Günther-Heinz Jähnick · Reeza007 · ISIL-KP · Methos31 · Albert Cardozo · 93.185.30.77 · MisstressD · 86.169.238.26 · Araldo81 · Xxlfussel · Flock · 2A02:810D:26BF:E6D0:CD81:F1A0:FA9E:5E7B · Katolophyromai · Jklamo · 117.233.41.29 · 87.97.131.183 · 2A02:810D:26BF:D974:E58C:E9F6:154F:F600 · 105.172.46.208 · KDS444 · Skblzz1 · Commander-pirx · 42.114.193.97 · The Photographer · Dannebrog Spy · Kiyoweap · 59.102.91.239 · ErikvanB · Bobyr · Pueblopassingby · 155.4.130.94 · Bayreuth2009 · 82.58.207.31 · Educayshun · Prioryman · La zimuth · Lessormore · EPO · Grüner Flip · Dudley Miles · Prof.lumacorno · ArnoldReinhold · Семен Владимиров · Jibi44 · Cristiano64 · Pemu · Gomera-b · Jonathunder · 83.59.137.163 · Chongkian · Llez · 27.253.107.189 · TheAmerikaner · UV · 91.23.2.143 · Ixicon · Parair · Buffaboy · Aboutmovies · ElbHein · 2003:45:5C21:3401:514C:9D0C:D23A:B3CF · Einsamer Schütze · ELApro · Inventis · ArisMethymna · 86.180.246.2 · 103.224.129.1 · Assayer · AlexanderKlink · 37.201.6.113 · Filo · Aaaatu · Ayalae3 · Guil2027 · 2600:1:C162:2D73:690A:D765:C100:53E4 · Rwendland · Giso6150 · 178.197.226.69 · CristianLopezPerez · Tim1357 · Callinus · Roman Miller · Llorenzi · بلال الدويك · Sainsf · Kandschwar · 66.243.212.164 · Alma Pater · Sacha47 · 86.180.245.138 · Giulia Ebohon · 2A02:810D:26BF:D974:AC95:90B3:E966:7FC · Nattes à chat · 107.77.169.11 · JoeHard · Denver Guardian · 87.21.17.51 · Elisardojm · CrucialFriend · Inter&anthro · Fortguy · Gerd Eichmann · YMS · Isaacvp · Brouhaha · Bambi spam · Ianuarius · Ντέιντζερ · Ikkenjouspdit · 86.183.18.39 · NotARabbit · Vycl1994 · Mkratz · Глнстый Карой · Grtek · Krib · 104.243.166.253 · Code · Thomas1313 · Matiras · Heather Elke · Romanm · Rococo1700 · Sundgauvien38 · Entbert · Ceoil · Kadellar · 86.183.27.67

Photo's copied from facebook

These two photo's, both of low resolution, are copied from facebook, File:11402749 10207033449338374 7490460781950105193 n.jpg (57 kb)and File:11174328 10206481581822031 5571782931645509548 o.jpg (139 kb) which I renamed to File:11174328 10206481581822031 5571782931645509548 o Mont Saint Michel.jpg . What is the policy of commons towards this? --Havang(nl) (talk) 08:44, 17 July 2015 (UTC)

The same policy as for everything else from internet: No upload unless you show it is your own work (if this is the case why dont you upload directly from the camera or PC?) or you have written permission from the photografer. I dont think there an option on Facebook for PD material as with Flicker. All considered it is highly unlikely you can upload these pictures. Besides the Commons has an enormous amount of pictures of the Mont Saint-Michel as this a popular tourist destination.Smiley.toerist (talk) 13:21, 17 July 2015 (UTC)

Replica´s in Bermeo

I discovered that a new replica Spanish galleon ship is being build in Bermeo. There is an other one in Category:Aita Guria (ship, 2005) but that one seems to be an older one. I dont suppose they regulary demast and rebuilt the ship every few years.Smiley.toerist (talk) 10:45, 17 July 2015 (UTC)

And wich type of ship is being build here?Smiley.toerist (talk) 11:03, 17 July 2015 (UTC)

There's also Category:Galeón Andalucía (ship, 2010). Perhaps we need a category for replica galleons to bring these together? - Jmabel ! talk 15:10, 17 July 2015 (UTC)

Either way, ll these should be under Category:Replicas of vehicles. -- Tuválkin ✉ ✇ 19:44, 17 July 2015 (UTC)

More precisely: Category:Replicas of sailing ships. It looks like the Bermeo build a ship like this every five years.Smiley.toerist (talk) 22:29, 17 July 2015 (UTC)

July 18

Redundant

@YaCBot: I believe that I've asked basically this same question before, and not gotten anything like a satisfactory answer. In this removal of information, how is the information redundant? Where else would one find it? Why is it not considered useful? - Jmabel ! talk 16:13, 14 July 2015 (UTC)

I raised the same concern at User_talk:McZusatz#YaCBot_consensus_needed, with the end result that it was brushed off without meaningful resolution or consensus.

Burying the information in hidden comments (which are highly problematic for automated searches) or saying it is still in the page history, remain problematic. A better solution is to use bucket categories showing the batch uploader, but purging these without consensus, or agreement with the uploader is not best practice for how bots are supposed to go about mass "housekeeping". --Fæ (talk) 16:21, 14 July 2015 (UTC)

Having a clickable link either in the source or author field is not only misuse of those fields but also led to quite some copyright infringements. I.e. not the author was attributed but the uploader. Commons pages are already too confusing to re users and I don't consider leaving this information is going to help.
Usually you'd find the name of the uploader in the upload summary (not in your linked case because it was uploaded with an old version of the bot). Otherwise you can find it as a comment in the page source text or you'd have to consult the history (like you have to do for uploads by Flickr upload bot as well).
I don't get why automated searches are not possible anymore. If you prefer a user category, I won't stop you adding that. --McZusatz (talk) 18:17, 14 July 2015 (UTC)

Best practice for bot operators is to gain consensus for any controversial action that affects the entire community, not say "I won't stop you" from fixing problems the bot has created.

As for relying on hidden text, the API wiki parser strips these out as standard, and many tools rely on the parsed text rather than the results of regex searches that may or may not give you the results you expect depending on server load. --Fæ (talk) 18:26, 14 July 2015 (UTC)

Please explain what "problems the bot has created". --McZusatz (talk) 18:29, 14 July 2015 (UTC)

Anyone previously relying on "uploaded by <account>" appearing in the image page information box, for example as a result of relying on one of the older mass upload tools, in order to automate processing of these images, or to create intersection reports with categories, now will be unable to see this on the image page. Having to hunt for possible hidden comments, or write new tools to interrogate old versions of the image page text (as the user account may not be the uploading account, depending on the tool used) is an entirely avoidable layer of complexity.

This housekeeping task is not a good fix to the issue of poor attribution, nor is it an agreed mass housekeeping task. It potentially changes hundreds of thousands of uploads and has never been an urgently required fix to an established problem.

Lastly, the burden of proof lies with the bot operator, not those raising tangible issues with the bot's actions. --Fæ (talk) 18:48, 14 July 2015 (UTC)

I am happy to change what the bot does if someone smarter than me can figure out something better. In the previous discussions there were more people in favor of the change than against it, but I am also happy to create a subsection for people to vote about that, if that is what you want. Though, it seems consensus that we can't leave it the way it is right now due to the reasons already mentioned. (Also worth to think about what will happen when we actually start using wikidata to store the data of the information template). (And lastly, bot owners and tool writers are apparently supposed to adapt their code from time to time. [c.f. "rawcontinue"]) --McZusatz (talk) 19:29, 14 July 2015 (UTC)

Having a clickable link in the source field can't cause copyright infringements; anyone depending on that field is already screwing things up. It is correctly stated as part of the source of the document; more correctly, provenance, but you can't tell me that Flikr is ever the original source of any work from 1909 anyway.--Prosfilaes (talk) 21:33, 14 July 2015 (UTC)

I personally find information about file uploader (who is not an author) at the file page to be irrelevant, same with users that transfer files from wikipedia. I am fine with hidden categories for keeping track of them. --Jarekt (talk) 20:01, 14 July 2015 (UTC)

Likewise. I'd prefer that I wasn't mentioned at all on a file that I uploaded from Flickr. I remember one file that I uploaded, File:Dharahara tower (17265163952).jpg was used on the front page of the Nepal Wiki after the earthquake, with credit given to me, even though I was only listed in the "File history" section. --ghouston (talk) 23:21, 14 July 2015 (UTC)

Actually I still see my name on every page where it's used on that Wiki: [10]. --ghouston (talk) 23:25, 14 July 2015 (UTC)

The reason I believe the removed information was useful: if someone has a problem with the image and wants it deleted, it makes it possible to identify and contact the uploader, who is likely to have something useful to say. Certainly it is not useful to inform Magnus's old bot! - Jmabel ! talk 00:24, 15 July 2015 (UTC)

You have a point there. However I suspect most notifications will come from scripts such as "Nominate for deletion", so they will still go to the old bot regardless of what you put in the information fields. Listing the uploader in the File history seems best, although my example above shows that people will misunderstand even that (possibly somebody who doesn't read English at all). I'm not sure what's best for the "legacy" files uploaded with only bot information in the history, but putting uploader information in Author or Source seems especially likely to be misinterpreted. --ghouston (talk) 01:19, 15 July 2015 (UTC)

If Commons translates to Nepali then maybe it's not even a language issue. Perhaps there's some way of modifying the File History section for the old files? Either adding a new entry or modifying the old one. --ghouston (talk) 01:28, 15 July 2015 (UTC)

I have just created a subsection below for user to submit votes expressing their opinion about this task. @Closeapple, Mr.choppers, Green Giant, Denniss, Rillke, Leyo, Fæ, Jarekt, Jmabel, Ghouston: I also invite the posters from my talk page to participate. --McZusatz (talk) 08:37, 19 July 2015 (UTC)

Unless I have missed something, the authority under which the bot is operating is set out in the original bot request of December 2013:

File-Cleanup:
1. Internationalization
2. General cleanup (com:regex: Dates, Format, Junk, Interwikilinks, ...)
3. ~~com:OVERCAT-cleanup~~ removed per discussion OverBot will solve those
4. Remove duplicate categories (regardless of their sortkey)
5. Remove {{Uncategorized}} if ~~more than zero~~ two or more visible categories are there
6. Mark as uncategorized if zero visible categories are found (Only hidden ones or no at all)

Of the approved tasks, none covers the task of deleting uploader information. The closest might be "general cleanup (junk)", but the information being deleted is not 'junk' even if there is an argument that it would be better displayed in some other location or in some other way. As the bot is operating in an unauthorized manner it is liable to be blocked, but I would hope that can be avoided as it is doing other useful things.

I have left a message on McZusatz's talk page asking for confirmation that the task will be stopped, if that has not happened already. This is purely to make sure Commons' bot policy is complied with; I make no comment on whether the actual task is a net positive or negative. Once that's confirmed, community discussion should continue with a view to reaching consensus on the best way to handle this. If consensus can be reached, the bot owner should then make a fresh application at Commons:Bots/Requests to have this task added to the bot's approved work. --MichaelMaggs (talk) 09:18, 19 July 2015 (UTC)

Use categories instead

Some users suggested to add a hidden category to such files. Personally, I don't like to spawn and spam automatically created categories like category:Uploaded by User Jacopo Werther (instead of the comment) and I'd prefer to add those categories based on individual needs. Such request could be filed on my talk page or the com:BWR. Thoughts? --McZusatz (talk) 09:21, 22 July 2015 (UTC)

Voting

Please use the space below to express if you generally agree/disagree with this specific action the bot is executing. The discussion, proposals and replies may be appended to the parent section immediately above.

The bot may only continue with this task if the support is greater than one half.

Support

Support --McZusatz (talk) 08:37, 19 July 2015 (UTC)
Support --Steinsplitter (talk) 08:45, 19 July 2015 (UTC)
Support --Denniss (talk) 08:59, 19 July 2015 (UTC)
Support --Yann (talk) 10:39, 19 July 2015 (UTC)
Support Uploader information is irrelevant for re-users of media. Thus, it should be removed from Author and Source fields. --Leyo 14:46, 19 July 2015 (UTC)
Support can be quite misleading to re-users unfamiliar to commons. --Zhuyifei1999 (talk) 18:17, 21 July 2015 (UTC)
Support per above. FDMS 4 21:59, 21 July 2015 (UTC)

Oppose

Oppose The specific action has not been specified, so this vote is fairly meaningless. If it is only to delete or hide in invisible comments information that many find useful, then this is highly unsuitable as a bot task and is not "housekeeping". I would support transforming the information, say by creating a batch upload category that would be equivalent. --Fæ (talk) 09:36, 19 July 2015 (UTC)
Oppose Information like this should not be deleted from the image page.--Prosfilaes (talk) 22:18, 19 July 2015 (UTC)
Weak oppose I do not see a big difference either way, it would be helpful to keep track of uploader info in a machine readable manner. For instance to notify uploader if file is going to be deleted for whatever the reason which would be useful for transparency of our deletion process. Might I recommend a separate "uploader" field? -- とある白い猫 ^ちぃ？ 13:09, 24 July 2015 (UTC)

Neutral

Neutral - I support the removal of the "uploader" information from the |author = line because this is misleading. However, I am opposed to completely removing the uploader information. There are several ways of indicating the uploader information including the upload log, the file history, and (hidden) user uploads categories. If it isn't clear in the upload log, it is not difficult for experienced users to look in the file history and guess who the (human) uploader was. However, inexperienced users might be confused, especially if they can't see hidden categories. I think we should solve the problem by expanding the {{Information}}/Infobox templates by including a separate (optional) |uploader = line for all future uploads. Transferring such information for existing files would be an appropriate action for a bot. Green Giant (talk) 13:25, 19 July 2015 (UTC)

That would a neat solution. Yann (talk) 13:30, 19 July 2015 (UTC)

Not really as that leaves the confusing/misleading information visible which in turn may lead to copyright problems for re-users. The maximum we should do is to convert this info into an "Uploaded by User:xxxx" hidden cat. Inexperiended users dont need such kind of info while experienced users may easily get it.--Denniss (talk) 20:14, 19 July 2015 (UTC)

If you can't read the page, then there's no magic on Earth we can do to get you to properly license the file. Should we delete the confusing information that they're on Wikimedia Commons from every image page, since Commons gets attributed a lot? Hiding random information until they get it right is simply not going to work.--Prosfilaes (talk) 22:24, 19 July 2015 (UTC)

Neutral While I totally agree that adding this in the |author field is a mistake, removing the information seems to be unncesarily contentious (some uploaders are finicky about this!); whenever I find an "uploaded by" credit when editing a filepage, I move it to the |source field. While a separate field would be perhaps better, this seems to be the simplest approach. -- Tuválkin ✉ ✇ 19:55, 21 July 2015 (UTC)
Neutral I support removing the uploader from the Information block, but rewriting it as a comment doesn't seem ideal. I expect there's no way that a bot using the API would be able to rewrite the File history. How about adding the uploader details as visible text, but outside the Information block and below the license and Flickr review templates, just above the File history? I.e., at the place where the bot has been writing the comment. --ghouston (talk) 10:43, 22 July 2015 (UTC)
Neutral per User:Green Giant above. Ariadacapo (talk) 10:48, 22 July 2015 (UTC)

Proposal to close

Unless anyone objects in the next day, I propose that the vote is closed as not supported; it is unlikely to be unambiguously supported even with a few more votes, as at the time of writing, supports = opposes + neutrals. It should be recognised that there is significant support for a bot task to delete uploader information from the source field, if it is replaced by either a separate "uploader" field or converted to an uploader category using the same information (as is now commonly the case with batch upload projects to aid easy automation and traceability). This has the potential to reduce confusion about attribution on reuse and keep the information displayed and accessible on the image page. It seems sensible that if this approach is taken, it should apply to previous actions by the same bot job. Thanks --Fæ (talk) 13:31, 24 July 2015 (UTC)

This section was archived on a request by: McZusatz (talk) 18:48, 24 July 2015 (UTC): Voting closed. Follow up discussion about the cleanup at Commons:Bots/Requests/YaCBot (confirmation)

Category for ponor and losing stream

Hello. I've just created Category:Losing streams, corresponding to en:Losing stream. But I noticed that Category:Ponors and en:Ponor were alreading existing. I cannot clearly see the difference. I suppose that a "ponor" is a particular case of a "losing stream" (due to karstic phenomena). Even on French wiki there are both articles (fr:Ponor and fr:Perte (hydrologie) = loss), without any link between them (I've just added them). I've posted this message on Commons:Bistro, too. Please correct these categories as necessary. Jack ma (talk) 16:28, 15 July 2015 (UTC)

"A ponor is a natural surface opening..." but "A losing stream ... is a stream or river that loses water as it flows downstream". I do not understand why you think that they mean the same thing? Ruslik (talk) 19:41, 15 July 2015 (UTC)

Losing streams due to karstic conditions are frequent in France. Here is a concrete example

: in which category should I put the photo on the right ? (Losing stream, Ponor or both ?). Thanks, Jack ma (talk) 06:52, 17 July 2015 (UTC)

It seems to be a river, so you have to use the Category:Losing streams for this picture. However, if this place is in a polje or a sinkhole, you might use Category:Ponors too. Géodigital (Talk with a geologist lynx) 22:15, 17 July 2015 (UTC).

I agree. A Ponor is really a synonymous of karstic loss (no need to create a new Category:Karstic losses). Ponors evacuate water underground, so they should automatically be in Losing streams as well (see most of the photographs). Thanks, Jack ma (talk) 05:53, 19 July 2015 (UTC)

Christopher Michel

Hi, Does anyone upload Christopher Michel's Flickr stream with a bot? Regards, Yann (talk) 19:13, 15 July 2015 (UTC)

At a glance, there's a lot good on there, but it's probably better to go manual, as there's some things like the Pluto image that would be misattributed by a bot, as well as some artsy black-and-white duplicates of images. Adam Cuerden (talk) 19:56, 15 July 2015 (UTC)

I think most of these are interesting, and there are 36,588 files. So manually, it would take ages. Regards, Yann (talk) 20:04, 15 July 2015 (UTC)

True. Although I suppose the other issue is getting them properly classified and used, which is going to take ages either way. May be easier with the Flickr categories, so, if we do use a bot, care is needed to preserve the necessary information. Adam Cuerden (talk) 20:07, 15 July 2015 (UTC)

5,801 R Photographs by Christopher Michel CatScan live report of new uploads

I have set an upload run with the following limitations:

Any image must have at least one Flickr tag that matches a Commons category name. This will hopefully avoid less interesting shots which have not been significantly tagged.
Images must have a longest side at least 4,000 pixels long. This will probably avoid derivatives and images taken by others.

The upload rate will be slow, probably just 300/day, so easy to keep a check on. It may take several days to get through this stream for all photos matching the criteria, so feel free to make suggestions for improving upload format as they go along. Stuff that can be improved easily using cat-a-lot or similar I suggest is left to be done that way, rather than building complex upload code. --Fæ (talk) 20:44, 15 July 2015 (UTC)

Thanks Fæ. Yann (talk) 22:27, 15 July 2015 (UTC)

I wonder if it's worth logging images that fit the second restriction but not the first? That'd let us easily check the remainder. Adam Cuerden (talk) 23:30, 15 July 2015 (UTC)

Keep an eye on User:Faebot/SandboxO. --Fæ (talk) 00:12, 16 July 2015 (UTC)

I'm seeing a lot of skipped photographs where the maximum side length is 2048, example, in fact about 250 photos have just been skipped in sequence (I'm uploading them going backwards in Flickr posted date). I'm not sure it's worth blanket uploading images under 4,000 pixels. There are some good quality sub-2,500px shots, but they are not consistently of great value. --Fæ (talk) 14:42, 17 July 2015 (UTC)

@Fæ: Great work (and great pics!). Note that Creator:Christopher Michel exists. Andy Mabbett (talk) 23:00, 18 July 2015 (UTC)

July 16

Broken history

User Till.niermann got busy with moving clock photos from Category:Time 00:44 to Category:Time 12:44 (but not 43 nor 45, apparently) against the established consensus. I would simply warn him and undo it, unless ponderous new discussion points are forthcoming, but I noticed this strange thing: At Category:Time 00:44 there is a {{Speedy}} tag, and its history suggests it has been there for the past 6 years. Kinda slow for a speedy, and unlikely that nobody saw this before. Broken history? (Pinging User:Docu.) -- Tuválkin ✉ ✇ 10:39, 18 July 2015 (UTC)

So categories only get added to pages when either somebody edits the page, or someone edits a template used by that page. If a category is added via a dynamic lua script or parser function, so that the page is not in the category at the time of save, but gets added based on some condition it fulfils later, that page won't really get added to the category in question until someone makes a null edit of that page (or edits it, or edits a template used by it. Note that a normal ?action=purge is not sufficient to trigger category additions). Bawolff (talk) 16:48, 18 July 2015 (UTC)

Two-minute guide to still-life photography

This video is an excellent, two-minute guide to food photography (but applicable to all still-life work). It's not under an open licence, but we should consider making something similar. The techniques shown require no fancy equipment. The audio is just music, so it would be easy to internationalise. Andy Mabbett (talk) 22:43, 18 July 2015 (UTC)

July 20

Category:Photo taken with camera X type Y

Can somebody please explain me why there is a bot running to add a hidden category to photo's putting them in categories like: Category:Taken with Olympus FE-5030 / X-965 / X-960? And please, also explain me what the use is of such categories? Dqfn13 (talk) 10:53, 15 July 2015 (UTC)

You mean BotAdventures (talk · contribs)? The purpose is for it to edit a small fraction of files on Commons with such categories, with the logic that "It gives a sample of images taken in real-world conditions from the particular camera." (see Bot request.) Pi.1415926535 (talk) 13:23, 15 July 2015 (UTC)

Sounds totally useless to me, categorising images on the camera it made... just "to give a sample of images taken in real-world conditons". I seriously thought this was some form of database of images to be used on severall Wikimedia projects. Not a collection of photo's made by Camera X type Y. Dqfn13 (talk) 16:38, 15 July 2015 (UTC)

Because a Wikipedia would never have an article about Camera X type Y, and a Wikibook would never have an article about the differences between cameras. And Commons is a Wiki; one of the rules of getting along in a Wiki is not stressing about what other people are doing when it has no effect on you. Who cares if it has a few categories tagging things that are irrelevant to you?--Prosfilaes (talk) 21:09, 15 July 2015 (UTC)

If something is irrelevant it does bother me, aspecially if it is done to a photo I've taken... There are more categories I don't understand like the date the photo was taken, for instance: Category:2014 in Amsterdam, placed on a building that is listed... As if you can see a difference betwee two years. Dqfn13 (talk) 22:05, 15 July 2015 (UTC)

Yes, what you mean by "irrelevant" is that these are metadata categories, like Category:Photographs taken on 2015-07-03, Category:CC-Zero, Category:Photographs by Joost J. Bakker‎, Category:JPEG files, Category:Oil paintings or Category:Photographs. I'm guilty of writing the bot, but not of creating (most of) the camera categories, which have been around for years. Theses categories make metadata browseable and linkable, to other related photos and any other related information (e.g., photographs of the cameras or their Wikipedia articles). The camera categories also have the side-effect of sneaking photos into the Photographs hierarchy, which has had its own existential issues. Using categories like this may not be ideal (mainly because of the intersection issue), but unless something like Commons:Structured data is successfully implemented some day, it's all we've got. I wrote the bot partly as an interesting coding project, since I'm not familiar with MediaWiki botting, and partly to populate these categories more systematically and for less effort then people have been doing by hand. The limit of 100 is imposed to reduce the number of files that need to be modified if Structured data is implemented. --ghouston (talk) 22:37, 15 July 2015 (UTC)

Because photos of New York City in 2000 don't have any real difference from photos taken in 2002. Or File:Burnt Historical Building in Lowell Feb 2010.jpg, which was much different in January and gone in March. Even in normal, more static, circumstances--and we don't know that that building will be there in 2016--the environment changes, year by year, decade by decade. Sometimes it will even be the things only of note to a few; the last or first of a particular street sign, or the tag sign of someone who will become famous.--Prosfilaes (talk) 23:25, 19 July 2015 (UTC)

big time problem in my file name APPLE I WATCH

just a one letter off.. can a master editor unblock the code of my spellcheck mistake

thanks in advance

i dont work for apple , i took this at the university, one student had it BD7772 David Adam Kess 25th July 2015 (UTC)

Done The file is now at File:Apple I Watch 2015 Model very cool.jpg. Cheers! BD2412 T 00:44, 26 July 2015 (UTC)
- In the future, please just use {{Rename}} on the file page, instead of bringing the matter to the Village pump. - Jmabel ! talk 05:41, 26 July 2015 (UTC)

This section was archived on a request by: Jmabel ! talk 05:41, 26 July 2015 (UTC)

- - thanks ǃǃǃǃǃǃǃǃ BD7772 David Adam Kess 25th July 2015 (UTC)

The Use of Iloko language, spoken by over 1.5 million people in the Philippines and migrants the world over

Iloko, Iluko or ILOCO, is spoken by over 1.5 million people in the Philippines, apart from Ilokano ( a person, people) who migrated to other parts of the world. The language has a rich base of tone and depth that is far easier to learn than other Philippine dialects or languages. An ortography on the Iluko Language has been in circulation for the past 20 years, as a means to standardized its use especially in the written form. Leading the cause for a standard written form is a weekly magazine called Bannawag published weekly by the Manila Bulletin Publishing Corporation. Bannawag magazine has become home and outlet of literary and journalistic works of poets, fiction writers and feature writers/essayists, who are respectable in their own professions. In the academic world, the University of California at Irvine (for confirmation) had authorized researches on Philippine languages, and the Iloko has been completely mapped out as a language distinct and viable for use in everyday communication and most especially in the written form. The University of Hawaii (Manoa) has a course on Iloko for use by the third generation of Ilokanos in the state of Hawaii and in other parts of the USA and the globe. Well-known academicians from the public universities in the Philippines are drawn to the course, and an annual or bi-annual conference has been in progress with Dr. Aurelio Solver Agcaoili as its proponent and over-all coordinator. With the new K-12 basic education curriculum which requires the use of Mother Language in Grades 1 to 3, Iloko is once more brought to prominence especially so since a big number of literary and textbook writers are put to task.

Verification on the above can be further made. This is a --Burgos Isabela (talk) 01:21, 17 July 2015 (UTC)proposal to include Iloko among the common languages in the world.

This is Wikimedia Commons, a free media repository. Are you interested in creating images or other media relating to iloko? Note that Wikipedia already has an article on Ilokano language in english and 47 other languages. Commons also supports iloko: {{Ilo}}. MKFI (talk) 07:40, 17 July 2015 (UTC)

Additionally, there already exists Ilokano Wikipedia. MKFI (talk) 09:31, 17 July 2015 (UTC)

The Iloko language is already included on Commons as a language that can be selected during the uploading of images (or other media). Regards, --OSeveno (talk) 16:18, 20 July 2015 (UTC)

Video of more than 1 gb

Hello, we make a project about the rare crafts in Macedonia, organized by our organization Shared Knowledge, and we successfully made first video of the first craftsman, but now we have a problem, because the video has size more than 1 gb (even after converting to .ogg). Any advice or tools how to upload so big file on Commons, please contact me. Thanks in advance --Ehrlich91 (talk) 19:16, 20 July 2015 (UTC)

You can use WebM to get a smaller file size for about the same quality as the ogg. Also you may look at Help:Server-side upload --McZusatz (talk) 19:23, 20 July 2015 (UTC)

Codex Sinaiticus

Hi, What about uploading images of the Category:Codex Sinaiticus from [11]? While there is a copyright claim, these are faithful copies of 2D old documents, so we could copies them here. However, getting the images may not be so easy. Opinions? Regards, Yann (talk) 21:56, 20 July 2015 (UTC)

I did look at this on a private request a few months ago for a different project. The images are quite easy to pull without any special tools as the site takes no special protection (I'll avoid publishing the technique here). The translations/transcriptions are non-free, as would be the data showing the locations of text in an image, so to a large extent the "true" value of these images is as shown on the source website as users can navigate the text, so displaying them here is an inferior experience. If nobody else has a go over the next few weeks, I could create a copy of a full set of images, or upload these myself if everyone is convinced that the website owner (The British Library) would not care and this would not damage my relationship with them. --Fæ (talk) 22:36, 20 July 2015 (UTC)

Thanks for your message. There are other copies here and here. Regards, Yann (talk) 22:51, 20 July 2015 (UTC)

July 21

Is there a way to flag an image as factually inaccurate/mis-identified without nominating for deletion?

This file: File:Sophie Anderson.jpg - is supposed to be Sophie Gengembre Anderson, an artist who died in 1903 at the age of 80.

Although several very amateur sites i.e., [12]; [13]; have long presented this as a photograph of the painter, it is simply impossible. Not least because at the earliest, this photograph was taken in the 1920s - at least 20 years after the supposedly 80-year old subject died. You'd think that if it was a deliberate hoax, they would have made the effort to find a more credible photograph actually showing a seventy-something woman in 1890s dress, not a young twentysomething in 1920s hairdo and glasses. Maybe it's another girl sharing the name Sophie Anderson. Anyway - any thoughts? It is probably an useful image for showing eyewear/hairstyle which is why I am hesitating to nominate for deletion, but I simply can't let this be presented as representing someone who it really cannot be. Mabalu (talk) 00:37, 22 July 2015 (UTC)

The only source information supplied is a blog site, so there's nothing to back up the public domain status either. That seems like enough to nominate it for deletion. --ghouston (talk) 01:30, 22 July 2015 (UTC)

A lot of empty categories in Category:Economics by year

I recently submitted a couple empty categories for speedy deletion but when I looked a little closer there seem to be a couple hundred empty categories in Category:Economics by year. I'm not sure if this is an accident or if it was done for some purpose, but before I swamp the speedy deletion board with a couple hundred requests I thought it would be better to discuss it first. It appears that there are approximately 650 out of 787 categories under Category:Economics by year that are empty currently. Reguyla (talk) 00:23, 22 July 2015 (UTC)

Since there have been no comments I am going to start submitting these. Reguyla (talk) 14:55, 22 July 2015 (UTC)

That was caused by this edit, which is now linking to non-existent cats like in Category:275 coins -> Category:275 in commerce. The template edit should either be reverted or all the now missing categories should be created. regards. --Ju Ta 15:22, 22 July 2015 (UTC)

Thanks, The template may need to be fixed, but the categories aren't missing, they have already been created. So we may need to delete the one set of categories and recreate them with the correct category structure. Reguyla (talk) 15:50, 22 July 2015 (UTC)

Replacements needed for Pywikibot components still using toolserver

Hi, Pywikibot has some components still referring to tools on toolserver.org, which are obviously completely broken. All are Commons related! ;-) :-/ See phab:T78462. @Multichill and Duesentrieb: .
What are the replacement tools for

Commons:Tools#CommonSense - https://toolserver.org/~daniel/WikiSense/UntaggedImages.php . Special:UncategorizedFiles ?
Commons:Tools#UntaggedImages - https://toolserver.org/~daniel/WikiSense/CommonSense.php, which recommended new categories.
https://toolserver.org/~multichill/filtercats.php, which finds images that are missing a license tag
Commons:Tools#Find Wikipedia/Commons dupes - https://toolserver.org/~multichill/nowcommons.php, which finds images on a project which are also present on Commons (comparing hashes).

John Vandenberg ^(chat) 03:10, 22 July 2015 (UTC)

Is the code available for these? If so some should be able to be rebuilt for the laps server. There are some differences in the 2 server clusters though and some functionality from the Toolserver cannot yet be duplicated on labs. Reguyla (talk) 14:53, 22 July 2015 (UTC)

I suggest that if these are part of the standard pywikibot modules, that they are taken out unless someone has a convincing case they are highly useful? I think it is fair to say that the filtercats thing for license checking can be done easily enough with catscan (obviously it will still miss non-standard templates), and the Commons dupes thingy is easy enough with a couple of lines of SQL which could be wrapped into a web page or you can use an existing simple web query service (the hash being nicely available on each wiki database). --Fæ (talk) 15:01, 22 July 2015 (UTC)

CommonSense is a very helpful tool, would be helpful to have it back. --Steinsplitter (talk) 16:52, 22 July 2015 (UTC)

Is the code available somewhere? Do you have a link? Reguyla (talk) 17:44, 22 July 2015 (UTC)

https://toolserver.org/~multichill/filtercats.php script which finds images that are missing a license tag is now handled by Commons:Bots/Requests/YiFeiBot (13), quarry #4509 or this CatScan2 query for new uploads --Jarekt (talk) 18:02, 22 July 2015 (UTC)

July 23

Peer review and document improvement request

This is a Peer review request to seek broader input to improve page: meta:Help:Form I & Affidavit (Customised for relinquishment of copyright as per 'free cultural work' definition) an option available under (Indian) Copyright act 1957 rules.

Mahitgar (talk) 04:05, 23 July 2015 (UTC)

[Image donations] Three historic atlases (national library of the Netherlands)

Earlier this week the national library of the Netherlands (KB) donated over 3100 images from 3 historic atlases (period 1690-1750) to Commons.

Each atlas has its own category

Category:Atlas van der Hagen (446 topographical drawings and prints from across the globe in various formats, beautifully colored and decorated with gold)
Category:Atlas Schoemaker (2579 topographical drawings, descriptions and prints of Dutch towns, villages and hamlets in the early 18th century.)
Category:Atlas Beudeker (133 images devoted to the northern and southern Netherlands.)

This was the first time the KB used the GLAMwiki-uploadtool, which can upload large numbers of images batchwise. This tools has been used by many GLAMs, including the Institute for Sound & Vision and the Peace Palace. So far more than 430.000 images have been donated worldwide using this tool.

The three atlases were digitized in the late ‘90s and put online on the Memory of the Netherlands website. This has been the source of the current donations.

Uploading to Commons is just the start, in the next couple of weeks the KB will work on

Expanding WP-articles about the atlases themselves, the creators/collectors (Andries and Gerrit Schoemaker, Cornelis Pronk, Abraham de Haen, Dirk van der Hagen etc) in multiple language versions
Creating / expanding related Wikidata-items
Promotional activities outside the community

The KB would like to invite all Wikip/m/edians to reuse the images as widely as possible, which could include

Using them in WP-articles (duh)
Further (sub)categorization of the images. A subdivision into country/city/place names would make sense, see for instance this list of place names for Schoemaker. Unfortunately it was not possible to do automatic subcategorization via the GLAMwiki-upload tool.
Adding geo-coordinates

Including these 3 atlases the KB has now released 7 historic atlases, see this overview. — Preceding unsigned comment added by OlafJanssen (talk • contribs) 23 July 2015‎ (UTC12:04)

This file is corrupt. Regards, Yann (talk) 10:40, 23 July 2015 (UTC)

Thanks Yann for pointig that out, I fixed it --OlafJanssen (talk) 11:33, 23 July 2015 (UTC)

Very interesting. I checked a few files from Category:Atlas van der Hagen, and it seems that there are a lot of artifacts, e.g. File:Atlas Van der Hagen-KW1049B10 002-NOVISSIMA TOTIUS TERRARUM ORBIS TABULA -Wereldkaart in 2 hemisferen.jpeg, File:17th century map of London (W.Hollar).jpg, File:MontdeParnasse.jpg. What's the compression level used? File:Atlas Ortelius KB PPN369376781-002av-002br.jpg seems better. Also the license should be {{PD-Art-100}}, not {{PD-old-100}}. And there is no EXIF data for these files. Regards, Yann (talk) 10:59, 23 July 2015 (UTC)

The images in Van der Hagen & Beudeker are direct copies the ones available on Memory of the Netherlands website. They indeed seem to be compressed quite a bit, not sure about the exact compression levels. Van der Hagen and Beudeker were digitized in the 90s, Ortelius only 2 years ago, that might might also play a role qualitywise ..--OlafJanssen (talk) 11:33, 23 July 2015 (UTC)

And also pls note that the files that do not start with "Atlas van der Hagen" were not part of the donation by the KB, they were already in the category before --OlafJanssen (talk) 11:36, 23 July 2015 (UTC)

Project page? Image tag?

Hi folks,

I have a project in Wikieducator that utilizes most of the coyote skull images here: https://commons.wikimedia.org/wiki/Category:Canis_latrans_skulls

Here's the project: http://wikieducator.org/Digital_Coyote

Because the project is in Wikieducator and not in Commons, it appears from the Wikimedia Commons point of view that no pages link to the extensive collection of coyote skulls.

So 2 questions occur to me: 1. Should I make a project page here that briefly explains the usage and importance of the images. 2. Should I make a short and simple template that would add a short blurb to each image explaining the same?

These questions came up because 3 images were marked for deletion because of permissions issues that I'm working on resolving. I'd like to protect the images from deletion because the entire project is 100% dependent on the several hundred images stored here.

Cheers

Declan Dmccabe (talk) 14:28, 23 July 2015 (UTC)

Declan, you could mark each individual image with {{Published}} (on the image talk page). However, if there is a permission problem which can't be solved then neither page nor template will help - an image with no permission would be deleted even if used by Wikimedia wikis. The only certain way to protect wikieducator use would be to copy the images locally to wikieducator. MKFI (talk) 06:25, 24 July 2015 (UTC)

Template:Authority control

I did a couple changes to Template:Authority control and also left a message about potentially doing some more if there is any interest. Both discussions are at Template talk:Authority control. Reguyla (talk) 20:57, 23 July 2015 (UTC)

Template:Authority control is waiting for a major rewrite in Lua the way en-wiki, pl-wiki and others did. We already have Module:Authority control but can not test most of the features yet since we are still waiting for "random access" feature on Wikidata. --Jarekt (talk) 02:38, 24 July 2015 (UTC)

Oh, well do we want to continue to wait until that happens or make what we have work in the meantime? Any idea how long it might take for "random access" to be approved? Reguyla (talk) 03:05, 24 July 2015 (UTC)

July 24

Image rendering issues

Tracked in Phabricator
Task T106516

File:The Residence of the Count of Wassenaar, Lord of Obdam, Kneuterdijk, The Hague.png
Today I uploaded above image, but it doesn't get rendered (on Commons) the way it is supposed to. The grayscale print either shows up too light or way too dark. Or the thumbnail gets rendered wrong. I tried re-uploading several times, whilst changing compression and even trying without any compression. The image has adjusted contrast, sharpness and made the image was desaturated. (with GIMP) Hopefully someone is willing to help me out ?
Regards, --OSeveno (talk) 16:07, 20 July 2015 (UTC)

That's interesting. The image seems to be converted from palette to greyscale, and below 475 pixels, a gamma of 2.2 is applied. Or a gamma of 1, in some of the old versions that you exported as greyscale images. Compare this with this. Have you tried adding a colour profile (not exactly sure what the best practices are for greyscale images)? — Julian H.^✈ 17:09, 20 July 2015 (UTC)

Looks like the same issue as Commons:Graphics village pump#PNG darkness at preview sizes. —LX (talk, contribs) 17:55, 20 July 2015 (UTC)

I tried a new file by adding a RGB profile, but no success. It's a pain. --OSeveno (talk) 19:32, 20 July 2015 (UTC)

~~I suspect its a case where the resampling filter we use happens to give particularly bad results for that specific image.~~ Bawolff (talk) 16:42, 21 July 2015 (UTC)

Hmm, looks like for greyscale files, if the gAMA chunk is missing, image magick assumes the image should be treated as having a gamma of 1. Might be a bug in image magick somewhere in there. I tried setting the gamma to 2.2 for the file, using pngcrush, seemed to fix it. Bawolff (talk) 11:50, 22 July 2015 (UTC)

Very interesting... Thanks for the help. Now if I only knew how to do this myself. (setting the gamma to 2.2) Can you please explain to me how I can do this ? Because I have other files with the same problem. Regards, --OSeveno (talk) 18:54, 22 July 2015 (UTC)

I used a program called pngcrush, using the -g 45455 option. I believe when saving images with the GIMP, there's an option to save the gamma chunk. Hopefully soon we will work around the issue in mediawiki, and all the images will just work. Bawolff (talk) 11:45, 23 July 2015 (UTC)

@OSeveno and Storkk: I submitted a work around for this issue, for review. How long it takes to get review can vary a lot, but once it gets reviewed, and then deployed (Less than a week after its reviewed), the issue will be fixed for all images on commons, and you won't have to do anything for any future images (old images would need a purge). 15:28, 24 July 2015 (UTC)

Just discovered a 2000-day-old vandalism

Here. Who can do better? --Ricordi samoa 02:12, 21 July 2015 (UTC)

This should get you a job offer from the Smithsonian.

--Hedwig in Washington ^(mail?) 16:28, 21 July 2015 (UTC)

Hedwig in Washington I had a list of several like that from ENWP. I found one a month ago or so that dates back to 2009. Its probably still there. Reguyla (talk) 14:54, 22 July 2015 (UTC)

There is a big patroll backlog, every help is needed. See COM:CVU :-) --Steinsplitter (talk) 16:54, 22 July 2015 (UTC)

Impressive, Reguyla! But you must provide evidence to compete ;-) --Ricordi samoa 07:28, 24 July 2015 (UTC)

Next time I see one I'll let you know. I stopped bringing them to people's attention because rather than make the fix they accused me of being pointy, trying to edit by proxy, etc. On ENWP its better to have vandalism, backlogs, POV pushing, article ownership, abusive admins and trolling than to build an encyclopedia, edit articles and foster a collaborative environment. Reguyla (talk) 14:38, 24 July 2015 (UTC)

July 22

Bots or bulk uploading of images from Flickr

Just for clarification this is not a licensing issue. My images are all licensed Creative Commons so I have no issues with them being used on Wiki* projects. Over the years pictures of mine have been added to the Commons and appeared on various pages on Wikipedia, normally added from Flickr.

I was a little surprised when I searched my name and saw that half of my Flickr archive has been uploaded to the Commons. Some of the images are things like family photos or pictures of my dog and the majority of them don't appear to be in use on any Wiki pages. What is the value in bulk uploading images like this? Are these bots or humans doing it? Again the images are Creative Commons so I don't care about copyright but I'm trying to understand why the bulk collection of my images is considered desirable or necessary. Especially the ones that -- from what I can tell -- don't have any use or purpose on Wikimedia sites.

I had originally posted this on Help Desk but was advised it might get a better response here.--Ajdelorenzo (talk) 22:29, 23 July 2015 (UTC)

Hi! First of all: Thanks for licensing all these mostly interesting images as CC-BY-[SA] 2.0. I am pinging user @Bodhisattwa: for a feedback who mostly (if not all) transferred these files to Commons. Btw, did you lost you password (considering available user Ajdelorenzo)? Gunnex (talk) 21:12, 23 July 2015 (UTC)

Gunnex, I think the question is: Why have files been uploaded, and why Commons is storing files, of this person's dog, and other images that are of personal interest. Just because someone puts images on Flickr with a license acceptable on Commons, does not mean every image there need to be plundered. Malcolm Schosha (talk) 22:04, 23 July 2015 (UTC)

Thanks for the reminder Gunnex I logged in. Malcolm Schosha has it right I'm just trying to understand the value in mass storage of images that are already stored elsewhere on the web. I don't see this as being within the project scope of being educational nor are the images being used on other Wikimedia projects. Again, I don't particularly mind that they are on here but it's more a question of why.--Ajdelorenzo (talk) 22:29, 23 July 2015 (UTC)

Being stored elsewhere on the web isn't relevant for whether they are in scope in Commons. Files elsewhere do disappear sometimes, e.g., people delete their Flickr accounts, or change the licensing. However I'm sure you are right that some files are transferred that have minimal educational use or where Commons already has plenty of equal quality material on the subject. It's up to individual Commons users what they transfer, although it's also up to individual Commons users which out-of-scope files to nominate for deletion. --ghouston (talk) 23:09, 23 July 2015 (UTC)

Well, in fact Commons is carrying out hundreds (thousands?) of deletion requests monthly which are related to project scope and some files like File:Polar bear mittens (6568023325).jpg may fullfill this condition. On the other hand: If someone plans to create (in a enciclopedic manner) the still nonexisting wiki-entry for the en:Frostbite Music Festival (which is already red-linked in two related articles) and is looking spontaneously at Commons for appropriate illustrations --> voilà!: your photos! In other words: Commons is dancing the balancing act for offering files which may [theoretically] realistically useful for educational purposes. And as we are not talking about some random [social media] shots/selfies from self-advertising deep underground bands, user Bodhisattwa may have encountered in your photos some kind of educational potential, saying: Wow! Nice shots, nice to have in CC. Gunnex (talk) 23:28, 23 July 2015 (UTC)

By the way, I'm guessing you know this, but just in case: you can change your licensing for individual photos you upload on Flickr. I'm a major contributor here on Commona, and my Flickr default is CC-BY-SA, but I usually upload my family photos as "all rights reserved" there; I figure if someone has a legitimate need for those, they can ask. - Jmabel ! talk 01:16, 24 July 2015 (UTC)

In any situation there are assumptions made about respect for personal space. There is an unspoken social agreement, and assumptions made, that the boundaries of personal space will not be violated [14]. Of course, if the license on Flickr allows it, then uploading it is legal. But that does not necessarily mean it is in all cases the right thing to do. Malcolm Schosha (talk) 13:59, 24 July 2015 (UTC)

If people want any of my images on here I fully support it and my licensing allows for it. I wouldn't want any of them deleted I'll leave it to the Commons to decide what is appropriate to the project scope. This conversation has helped me clarify what is happening and that it was not a bot. Thank you everyone for the replies. --Ajdelorenzo (talk) 16:06, 24 July 2015 (UTC)

Files without {{Information}}

Hi, I want to bring attention to a backlog not many of us are aware of. There are about 500,000 files without propoer {{Information}} template usage. 100,000 of these are non-self without a proper URL. We have been discussing how to deal with this problem in Wikimania and I wanted to bring attention to it. -- とある白い猫 ^ちぃ？ 19:41, 16 July 2015 (UTC)

There is no requirement to use it. --Fæ (talk) 22:39, 16 July 2015 (UTC)

Fæ, I think {{Information}} or similar infobox templates are certainly needed at this point. Of all the millions of files on commons only 500K lack these templates. I am a bit confused, are you objecting the effort to fix this? -- とある白い猫 ^ちぃ？ 02:39, 17 July 2015 (UTC)

Any large change (I consider anything affecting over 100,000 pages to be large) should have a documented consensus, or existing guideline/policy itself supported by consensus, before we release Skynet to do the job for us. --Fæ (talk) 10:58, 18 July 2015 (UTC)

@Fæ: Yeah... That is why I posted this here. To engage such a discussion. :) I think skynet-phobia in these type of a task is fair and such concerns must be addressed in a satisfying manner.

We can either offer suggestion and let humans handle this task by hand or we can fix the more obvious problems with a bot and let the humans handle problems where bot does not have confidence.

-- とある白い猫 ^ちぃ？ 23:08, 18 July 2015 (UTC)

@Fæ: So do you have a specific concern we can address? I'd rather not delay work on this issue unless anyone has a good reason to object. Objecting for the sake of objecting would be quite disruptive. -- とある白い猫 ^ちぃ？ 16:18, 19 July 2015 (UTC)

The specific concern is that nobody has made a specific proposal. A test run on 100 old files without any current templates and adding templates that have existing classes that enable future machine-readable data projects, as this appears to be the rationale to make the change at this time, would be useful to discuss, rather than open-ended hypothetical discussion about the concept which people are taking as a proposal. Thanks --Fæ (talk) 18:07, 19 July 2015 (UTC)

(Edit conflict)This is an aspect of the WMF's meta:File metadata cleanup drive, in that the use of information (or artwork, photograph, etc) templates is needed to make the image data machine readable, and enable a later move to using some type of wikidata-like database for such information. Unfortunately, there are still some editors who will war about the conversion of 'their' file pages to such a format, in the lack of any actual Commons policy about the formatting of file pages. I think that, in order to efficiently move forward with this, such a policy (that, at the least, documents that there is a consensus for file pages to be converted to use such templates) needs to be created. A familiarity with at least the 'premise' of Commons:Machine-readable data is worthwhile, for background. Revent (talk) 22:43, 16 July 2015 (UTC)

@Fæ: Yes, there is indeed no 'requirement' to use such templates, but I think it should be made clear that their use is considered 'best practice', and that it is inappropriate to revert such a change to a file page on the basis of personal preference. Revent (talk) 22:45, 16 July 2015 (UTC)

Only one template has been mentioned. As for the use of classes, any template can be adapted to meet the MRD principles without most users seeing any difference. We lack a visionary proposal and a commitment from the WMF to support its implementation. --Fæ (talk) 22:53, 16 July 2015 (UTC)

The error category being referred to (with the half-million files) is Category:Media missing infobox template... there are other 'infobox templates' (Artwork, Photograph, Book, Map, etc) that serve the same purpose. Most of the contents of that category are 'old' uploads (File:1 5 2 55.svg as a random example) that have rather broken file pages to begin with... they typically have a lack of a clear source, author or other required information. The problem I have seen is where people were reverting the conversion of such a page to use an infobox template on the grounds that it was useless.... while for a 'particular' file adding a template with 'unknown' fields might not be particularly helpful, doing it 'project wide' seems worthwhile if we are even going to move forward on improving the way we handle metadata. What I would propose is not that we 'require' uploaders to use such templates, but that we endorse the wholesale conversion of such pages to use those templates... even if done 'imperfectly', as long as we do not introduce actual 'errors' in the process it is a step forward. Revent (talk) 23:15, 16 July 2015 (UTC)

Then please create the proposal. Once the community agrees a formal proposal for consistency of machine readable data, the WMF can decide whether it should implement anything to support it, or we an unpaid volunteer can just do it if they wish. --Fæ (talk) 10:48, 18 July 2015 (UTC)

It is obvious that nobody would seriously disagree on the addition of an infobox template to each file page. --Leyo 12:43, 18 July 2015 (UTC)

It depends on the scope of the proposal. Some will want harmonization to a small number of templates, others will want standardization of fields. These are potentially areas of contention as our working practices vary and "best practice" as defined in different places can be contradictory. Note that supporting classes to make MRD possible need not rely on transcluding a template. --Fæ (talk) 12:51, 18 July 2015 (UTC)

Depends how? After information template is put in and generate a standardized machine readable output, you can restructure it to your hearts content as needed. The argument here seems to be keeping a mess or not which is not much of a discussion. If you have suggestions on improving how such tagging needs to be conducted, go for it. -- とある白い猫 ^ちぃ？ 16:23, 19 July 2015 (UTC)

See above, there is no point in repeating it. --Fæ (talk) 11:41, 20 July 2015 (UTC)

You could have saved everyone a LOT of time simply stating something like "I'd like to see a few test edits by the bot, please" you know. Just saying. -- とある白い猫 ^ちぃ？ 12:50, 21 July 2015 (UTC)

I find it baffling to see pushback (or wikilawyering) around such a super obvious common sense proposal. We are listing {{Information}} as a best practices example at Commons:First_steps/Quality_and_description. --Dschwen (talk) 15:49, 18 July 2015 (UTC)

I am baffled too about the surreal detour the discussion took. Commons do not have many policies, for example we do not have policy about removing {{Information}} template from files but if someone have tried that he would have been blocked in no time. We also do not have policies about requiring them but if anybody is willing to spend their time fixing such files than the effort should be appreciated. But let's go back to とある白い猫 original point: Lack of the infobox template is hiding the fact that many files have unclear or questionable sources and lack permissions. For example: 1, 2, 3, or 4. I do not have any reasons to believe that any of those files were not released under stated license, but it might be hard to verify. --Jarekt (talk) 04:53, 19 July 2015 (UTC)

So I will post sample edits today for your consumption. -- とある白い猫 ^ちぃ？ 03:56, 24 July 2015 (UTC)

@Fæ: , take a look at Special:Contributions/Dexbot. It has a few sample edits of the nature we discussed above. -- とある白い猫 ^ちぃ？ 15:08, 25 July 2015 (UTC)

July 17

Deletion requests

Why is Commons:Deletion requests/2015/07 broken after July 13th? I tried to fix the problem, but obviously to no avail. --Magnus (talk) 11:14, 20 July 2015 (UTC)

There's only so many templates you can inline into a page. The DR page has broken that limit.--Prosfilaes (talk) 11:25, 20 July 2015 (UTC)

That is a testament of how broken it is. :p -- とある白い猫 ^ちぃ？ 15:10, 25 July 2015 (UTC)

Help with images...

I don't know if this is the right place, but in any case I recently nominated Central Committee elected by the 16th Congress of the All-Union Communist Party (Bolsheviks) for Featured List candidate on English WP. Anyhow, one user (Seattle) wrote

File:Andreev Andrey Andreevich.jpg, File:Alexey Badaev.jpeg, File:Bubnov andrei.jpg, File:Khatayevich.jpg, File:Stamp of USSR 1048.jpg, File:Kirow.jpg, File:Lazar Kaganovich.jpg, File:Rus Stamp-Gamarnik YB.jpg, File:Vlas Czubar.jpg, File:Bucharin.bra.jpg, File:Kosior.jpg, File:Krupskaja.jpg, File:Gleb Maksimilianovich Krzhizhanovskiy.jpg, File:Valerian kuybyshev.jpg, File:1988 CPA 5986 cropped.jpg, File:Georgy Lomov-Oppokov.jpg, File:Mamia Orakhelashvili.jpg, File:Petrovskiy GI Soc Kiev 1937 01 p10bis.jpg, File:Piatnicki.jpg, File:Globus-1935-05-Pavel-Postyshev-foto.jpg, File:Yury Pyatakov.jpg, File:Rudsutak.jpg, File:NikolayShvernik.jpg, File:Stalin lg zlx1.jpg, File:MichailTomski.jpg, File:Klim voroshilov.JPG, File:Bryuhanov.jpg, File:Shalva Eliava.jpg, File:Grigory Naumovich Kaminsky.png, File:Kosarev.jpg, File:Krinicki.jpg, File:Solomonlosovsky.jpg, File:Mezhlauk Valery Ivanovich (1893-1938).jpg, File:Levon Mirzoyan.jpg, File:Boris Pozern.jpg, File:V V Ptuha.jpg, File:Sokolnikov.jpg, File:IP Uborevich.jpg, File:1936 genrich grigorijewitsch jagoda.jpg, File:Yakir Iona.jpg need PD US tags, if they're PD in the US.

Sources dead for File:Alexey Badaev.jpeg, File:Andreev Andrey Andreevich.jpg, File:Bubnov andrei.jpg, File:Stamp of USSR 1048.jpg, File:Kirow.jpg, File:NikolayShvernik.jpg, File:Stalin lg zlx1.jpg, File:Klim voroshilov.JPG, File:1936 genrich grigorijewitsch jagoda.jpg, File:Yakir Iona.jpg

Sources needed for File:Lazar Kaganovich.jpg, File:Krupskaja.jpg, File:Kosior.jpg.

Could someone here help me with this? --Trust Is All You Need (talk) 07:58, 24 July 2015 (UTC)

One of you either uploaded one of the images in teh first place, active edit history on the image (i contacted you when the uploader was inactive; looked at edit history) or uploaded a new version of the image. Could any of you help? If not, aren't these images in danger of being deleted? --Trust Is All You Need (talk) 08:13, 24 July 2015 (UTC)

If they don't have an explanation for why they are free in both their source county and the US, they can be deleted, for sure. Fixing that would require information about the time and place of original publication and some expertise with the copyright laws of all relevant countries. For example, File:Globus-1935-05-Pavel-Postyshev-foto.jpg says it was published in a magazine in 1935, and claims that it's public domain in Russia and Ukraine, but who knows about the US? Other photos only give a date and don't say if it was the publication date or the date the photograph was taken. --ghouston (talk) 00:22, 25 July 2015 (UTC)

As I said on en.wp, everythng on the post stamps is free, see e.g. a recent discussion here (closed to the bottom).--Ymblanter (talk) 07:44, 25 July 2015 (UTC)

Public domain in the source country doesn't imply that it's public domain in the US. Although that seems like something that Commons could consider making an exception for, like it does with FoP sculptures. If it's public domain in the source country, and nobody has tried to enforce copyright in other countries, then let it in. --ghouston (talk) 23:36, 25 July 2015 (UTC)

July 25

Arabic calligraphy/Styles/Hijazi

I have just seen that we have Category:Arabic calligraphy/Styles/Hijazi. We don't usually have hierarchies in category names, but before I nominate it for renaming, I thought I should check in case there's a reason for it, or it's one of many. Andy Mabbett (talk) 13:33, 26 July 2015 (UTC)

Nope, not a good name, nominate the category for discussion. - Jmabel ! talk 16:23, 26 July 2015 (UTC)
- Done. I did find some others in the same pattern. Andy Mabbett (talk) 23:27, 26 July 2015 (UTC)

File:Women_of_Artas.jpg

The photo 'Women of Artas' which was, I think, rightly attributed to my grandmother Grace Crowfoot, is dated 1944. This has got to be wrong, as by that date Grace Crowfoot was back at home in the UK - her period in Artas was in the 1930's. I think the confusion is because she published material on Artas in the UK (probably including the photo) in the 1940s; but the photo must date from about ten years earlier. This is a minor point, but what happened in Palestine in the 1940s does get people exercised for various reasons. — Preceding unsigned comment added by 2.219.73.50 (talk • contribs)

I'll make an appropriate edit, but just so you know: in the future you can make an edit like this yourself, and leave an explanation on the file talk page. - Jmabel ! talk 16:25, 26 July 2015 (UTC)

I added a few cats, cropped it, and fixed something in the info box. -- Tuválkin ✉ ✇ 20:26, 26 July 2015 (UTC)

Category:Postcards

I've opened a discussion here as to whether "Postcards of X" (where X is a location) should depict X or be produced in X (or even both); input welcome. Rodhullandemu (talk) 22:29, 26 July 2015 (UTC)

Photographs by Haraldbischoff

There has been recent discussion on email lists about legal actions defending moral rights, resulting from reuse of Commons photographs. Please feel free to add views or evidence to Commons:Administrators'_noticeboard#Legal_action_resulting_from_photographs_by_Haraldbischoff and help decide if any action or change is needed. Thanks --Fæ (talk) 22:43, 26 July 2015 (UTC)

July 27

Proposal to create PNG thumbnails of static GIF images

The thumbnail of this gif is of really bad quality.

How a PNG thumb of this GIF would look like

There is a proposal at the Commons Village Pump requesting feedback about the thumbnails of static GIF images: It states that static GIF files should have their thumbnails created in PNG. The advantages of PNG over GIF would be visible especially with GIF images using an alpha channel. (compare the thumbnails on the side)

This change would affect all wikis, so if you support/oppose or want to give general feedback/concerns, please post them to the proposal page. Thank you. --McZusatz (talk) & MediaWiki message delivery (talk) 05:08, 24 July 2015 (UTC)

The two thumbnails on the right look exactly the same. --Dschwen (talk) 20:01, 25 July 2015 (UTC)

Not here they don't. Andy Mabbett (talk) 10:12, 26 July 2015 (UTC)

Maybe if you are on a high-dpi display they would look similar. Bawolff (talk) 16:24, 26 July 2015 (UTC)

Me using Win XP/Firefox(latest version) and the PNG thumbnail looks much better with antialiasing than GIF. -- Sameboat - 同舟 (talk · contri.) 03:45, 27 July 2015 (UTC)

Anyway, the bug only affects GIFs with single-palette-color transparency (not "alpha channel"[sic]!), and PNG resizing has had problems with other types of images... AnonMoos (talk) 03:19, 28 July 2015 (UTC)

Longest file names?

I have noticed that the files with the longest names are the most likely to contain promotional material in the file names, winding garden-path descriptions, incoherent grammar, and other kinds of improper or inappropriate text. Is there a place where the files with the longest names are listed? If not, is someone able to generate such a list? I'm interested in seeing a list of, say, the 10,000 files with the longest titles, excluding redirects, to check for such issues. BD2412 T 19:58, 25 July 2015 (UTC)

@BD2412: User:Fæ/Long filenames. If useful it could be scheduled to refresh regularly (truncated at 2,000 files due to mediawiki page length constraints). Note that non-ascii names take more bytes even though they display as fewer distinct characters.

--Fæ (talk) 14:48, 26 July 2015 (UTC)

Thanks, that is perfect! BD2412 T 14:55, 26 July 2015 (UTC)

Okay, right off the bat I have noticed that about 1,800 of the files on this initial list (and doubtless many more) are autogenerated lines of borderline gibberish like File:ABS-5232.0-AustralianNationalAccounts-FinancialAccounts-FinancialAccountsSummaryConsolidatedPublicNonfinancialCorporationsGeneralGovernmentNonfinancialPubli-NetTransactions-ConsolidatedSubsectorLevel2-TotalFinancialAssets-Net--A3405570W.svg, which is apparently the directory address to get to the chart in question, plus part of the name of the chart (the chart itself is a graph of financial transactions by private corporations in Australia from about 1988 to 2015. If the entire group is like this, I'd find out which ones are in use and delete the rest. Without an internal key to explain the meaning of the numbers, the graph is largely useless. BD2412 T 03:16, 27 July 2015 (UTC)

It has a description that attempts to explain it, so I'm not sure that the lack of a key on the chart itself is grounds for deletion. Maybe the operator of the bot that has been uploading an updating these files (User:99of9) could come up with a better naming system? --ghouston (talk) 23:12, 27 July 2015 (UTC)

There is no key on the charts themselves per remember to keep language-specific information in the caption if it's not too inconvenient so that they can easily be used in other language wikipedias. This was a deliberate choice. Of course you are welcome to make a version with labels if you wish. --99of9 (talk) 23:48, 27 July 2015 (UTC)

If you asked for this file to be renamed, what would you call it? --ghouston (talk) 23:16, 27 July 2015 (UTC)

There was discussion of the name format when the bot was approved. Short is not a crucial criteria for large complex sets. --99of9 (talk) 00:19, 28 July 2015 (UTC)

Regarding deleting all the files that are not in use, I really think that would be counterproductive. Firstly they are a complete updated set of time series data put out by the Australia Bureau of Statistics. Secondly they are fairly well categorized by topic in Category:Statistics of Australia, and via their source indexes in Category:Images using data from the Australian Bureau of Statistics. This means that when we want time-sensitive data in a Wikipedia article on an Australian topic, it is fairly easy to get whichever chart we need, rather than generating it manually. (As an exercise: go to your national equivalent of w:Economy of Australia, and find out how out of date each graph is!) There are 317 graph uses to date, but there would be less than 10 if I had to create them individually. How many more can be productively used in Wikipedia? I'm not sure, I'd estimate a few hundred more. Do you want to delete them before we find their use? The ABS considers the data educational/useful enough to be worth collecting and publishing, so I presume someone somewhere has a use for many of them. --99of9 (talk) 00:10, 28 July 2015 (UTC)

I see that these are updated regularly. However, we have plenty of series of files that have more coherent file names, avoiding what seem at first glance to be just strings of buzzwords. There must be some way to name these files more coherently. BD2412 T 03:10, 28 July 2015 (UTC)

July 26

FINAL big time problem ' TEN FILES; one letter off

Category:FLACSO,_Ecuador all ten in the category are off by a letter

The school is called FLACSO not as i have it spelled _Flasco,

thanks ǃǃǃǃǃǃǃǃ BD7772 David Adam Kess 25th July 2015 (UTC)

The Latin American Social Sciences Institute or Latin American School of Social Sciences (Spanish: Facultad Latinoamericana de Ciencias Sociales or FLACSO) is an inter-governmental autonomous organization for Latin America and the Caribbean dedicated to research, teaching and spreading of social sciences. It was created on April 17, 1957, following a UNESCO initiative at the Latin American Conference on Social Sciences in Rio de Janeiro. Its membership is open to Latin American and Caribbean countries that subscribe the FLACSO agreement. Current members include: Argentina, Bolivia, Brazil, Costa Rica, Cuba, Chile, Ecuador, Honduras, Guatemala, Mexico, Nicaragua, Panama, Dominican Republic and Suriname.

As I said above, "please just use {{Rename}} on the file page, instead of bringing the matter to the Village pump." - Jmabel ! talk 16:22, 26 July 2015 (UTC)
- In any case, these are now also done. BD2412 T 14:41, 27 July 2015 (UTC)

Easy way to find images with only one category?

Is there an easy way to find which images are present in only one single category (excluding hidden categories)? Specifically, I would like to find all images in Category:2015 Royal International Air Tattoo which have not yet been added to any aircraft categories. MKFI (talk) 17:22, 27 July 2015 (UTC)

Gallery details gadget helps, but I would still like to have a query such as cat scan or similar. MKFI (talk) 17:23, 27 July 2015 (UTC)

Well, an SQL query would be the first thing that comes to mind (with group by page_id and count(..)=1 --Dschwen (talk) 17:32, 27 July 2015 (UTC)

http://quarry.wmflabs.org/query/4545 Bawolff (talk) 20:52, 27 July 2015 (UTC)

Thank your, that works nicely. I didn't know about Quarry. MKFI (talk) 12:02, 28 July 2015 (UTC)

July 28

Proposed rename of Flag of Jihad.svg to File:Flag of Taliban (reversed).svg

This filename currently suffers from a bit of original research and quite a bit of POV issues. Calling it Flag of Taliban (reversed).svg nullifies this problem by giving it a factual basis. Please comment on the talk page if you agree with this or not. -- とある白い猫 ^ちぃ？ 15:08, 28 July 2015 (UTC)

July 29

Categories for Communautés d'agglomération / Agglomeration Communities

The category names for these are not standard: some use the English term and some use the French term. I just changed six of them so that all the ones under Category:Communautés d'agglomération in France by department would use the English term. I did this because 1) most of the ones there already used the English term and 2) the {{Departments of France}} template doesn't work if the subcategory names aren't consistent. (Maybe that template should be on the subcategories anyway, instead of the parent category.)

I see that the higher-level categories under Category:Communautés d'agglomération in France use the French term, as do all but two of the ones under Category:Communautés d'agglomération in France by region.

So the question is, which do we want? There is a general preference for category names to be in English, but there are exceptions. I see that English Wikipedia uses a mix, under en:Category:Agglomeration communities in France. --Auntof6 (talk) 01:44, 27 July 2015 (UTC)

Anyone? --Auntof6 (talk) 03:40, 30 July 2015 (UTC)

Autozug

I took some pictures of an unloading of an Autozug. What unusual type of car is this one?Smiley.toerist (talk) 09:19, 29 July 2015 (UTC)

That's a Nissan Cube. --Magnus (talk) 14:12, 29 July 2015 (UTC)

Also known as brick. :D -- とある白い猫 ^ちぃ？ 14:56, 29 July 2015 (UTC)

Pictures of some places in Spain needed!

Hi! We're a group of Wikimedians mostly in Spain who are trying to improve the coverage of municipalities in Spain. We found that out of 8122 municipalities, 2239 did have no picture at all in Commons. Ashamed, we've been making our best. In fact we have taken or found photos from almost 200 municipalities, but more than 2000 unpictured places are still way too many.

What we need your help for is getting pictures of municipalities in Spain. You can find lists at Wikiproyecto:Ningún municipio español sin fotografía. The provinces that are in the worst condition are Salamanca, Zamora, Toledo and Guadalajara. Of course there are many pictures from their capitals, but, surprisingly, places just five kilometers from Salamanca or Zamora have no pictures in Commons.

Other provinces have many places to picture too.

So if any of you happens to be around Spain this summer, please upload pictures. It doesn't matter if the place is ugly, this is no beauty contest. It is that we don't have pics. Nobody in Wikimedia has the pics.

Thanks a lot!

B25es (talk) 13:26, 29 July 2015 (UTC)

For the record, there’s 631 images at or under Category:Unidentified locations in Spain. (Not to mention that among millions of uncategorized images, some are necessarily about a Spanish municipality.) Maybe that’s a good place to start? -- Tuválkin ✉ ✇ 00:35, 30 July 2015 (UTC)

We're trying there too, with little -but some- success. Thanks for the hint. B25es (talk) 05:51, 30 July 2015 (UTC)

Ex post facto attribution on enwp imports

I have seen on several occasions an image that is uploaded to both enwp and Commons but wasn't transferred with a tool or bot. So the Commons attribution is not verifiable because there's no "original upload log" or any of the usual bot specifics of the license. If I go to correct this, it looks like I'm on my own to make a few manual edits. (Yes, if it's the same uploader/author, not a big deal, but I'm talking about other editors who import others' work manually.) Is there a tool or bot that can add the enwp "original upload" attribution info and fix the licensing details after the Commons import (ex post facto)? I haven't seen a document from either site on how to deal with these situations. – czar 04:18, 30 July 2015 (UTC)

Found my answer: toollabs:magog/fileinfo.php generates the text just like I wanted. Help me circulate this tool so more people can see it? – czar 06:33, 30 July 2015 (UTC)

New buttons and form controls in the watchlist

The new buttons and form controls take more space (more than 100px for me). Is it only me or do other users also have the feeling that especially the select (the dropdown) for the namespace selection is oversized and its entries have too much padding so usability is impaired on Desktop devices.

On the one hand, I need a Linux or Mac command line in order to contribute to MediaWiki's code base (and run the tests properly and having copy&paste available), on the other hand desktop usability is impaired with this change. -- Rillke^(q?) 20:24, 29 July 2015 (UTC)

I also agree with that. Smaller buttons and dropdown would better. Regards, Yann (talk) 20:40, 29 July 2015 (UTC)

I thought I opted out of these ridonkulous style changes when I selected the Monobook skin. These cosmetic changes look horribly out of place in anything but Vector. Since they've obviously not been tested with other skins, why not just leave the other skins alone? —LX (talk, contribs) 22:15, 29 July 2015 (UTC)

The techies again seem to live in their own world, testing only their environment (skin) and not the others. Lost of space wasted for nothing (plain empty). --Denniss (talk) 22:55, 29 July 2015 (UTC)

If one wanted to get rid of inconvenient users who use outdated stuff like something without touch device, this would be the right strategy -- wear them down until they give up. -- Rillke^(q?) 23:13, 29 July 2015 (UTC)

«If»…? -- Tuválkin ✉ ✇ 00:03, 30 July 2015 (UTC)

Hi. I can assure you I tested this in MonoBook (c.f. phab:T99256#1486494), and it intentionally looks different in MonoBook and Vector - the styles in Vector clash much worse than the theme that is applied to MonoBook right now. It's not perfect, which is why we have bugs like T100300 to improve it. Legoktm (talk) 02:32, 30 July 2015 (UTC)

Wow, so the clashing pastel coloured Duplo look is intentional! How many user complaints have there been about the "Mark all pages as visited" button not being green enough and the "Go" button not being blue enough? Why is so much time spent on nonsensical fiddling with things that aren't broken? There are so many other things that should have "drop everything else until it's fixed" priority: the Upload Wizard that never works, the lack of a derivative works upload process, the weird insistence on converting perfectly fine SVGs to PNGs with a severely crippled utility, category contents watch listing, and category move functionality... to name a few. —LX (talk, contribs) 14:14, 30 July 2015 (UTC)

To be honest, I like nice and big buttons. This enhances usability quite a bit. --Sebari (talk) 23:37, 29 July 2015 (UTC)

Ugh, ugly, too big, eeew. If some users want big buttons then make a new "Lego/Mickey Mouse" skin. A key buzzword for website design used to be "real estate", which was always at a premium; is this old fashioned in the tablet age? If there is research that shows users demand these buttons, then it is easy enough to have them pop up on demand rather than wasting a big chunk of everyone's watch-list screen. --Fæ (talk) 23:44, 29 July 2015 (UTC)

phab:T107311 is tracking making the forms less spacy. Legoktm (talk) 02:15, 30 July 2015 (UTC)

Oh good, I see the forced side-scrolling to get to the [Go] button on small monitors has already been mentioned there. Really, who thought that was a good idea? DMacks (talk) 14:38, 30 July 2015 (UTC)

I dropped this into my monobook.css:

.oo-ui-buttonElement-framed.oo-ui-flaggedElement-constructive > .oo-ui-buttonElement-button {
   border: 1px solid #c9c9c9;
   background: #eee linear-gradient(to bottom, #fff 0%, #ddd 100%) repeat scroll 0% 0%;
}
.oo-ui-buttonElement-framed.oo-ui-flaggedElement-progressive > .oo-ui-buttonElement-button {
   border: 1px solid #c9c9c9;
   background: #eee linear-gradient(to bottom, #fff 0%, #ddd 100%) repeat scroll 0% 0%;
}
.oo-ui-buttonElement-framed > .oo-ui-buttonElement-button {
   padding: 0 0.4em;
}

It makes things a bit less hysterical. —LX (talk, contribs) 14:36, 30 July 2015 (UTC)

Thanks for that, LX. For what it's worth, I agree with the general sentiments expressed above by Rillke, LX and Fæ. Storkk (talk) 15:14, 30 July 2015 (UTC)
+1 -- Tuválkin ✉ ✇ 22:46, 30 July 2015 (UTC)

Hi, the change of watchlist interface was indeed deployed prematurely (and now reverted), and we missed some of the display issues with it (mostly there wasn't meant to be that much whitespace, and it behaved strangely on small screens). I didn't author or accept it myself, but I reviewed it and didn't flag them. We're going to be trying again, with feeling this time, probably next-next week (week of 10 August). Please watch phab:T99256 for updates (you can "Subscribe" if you have a Phabricator account to receive updates by e-mail), I'll make sure there's a testing wiki with the patch set up and linked from that patch at least a few days earlier, for everyone to play with and comment. Matma Rex (talk) 20:13, 30 July 2015 (UTC)

July 30

Display problems

Can someone tell why this file is not displaying properly? File:US monthly wind capacity factor.svg

It displays properly in http://tools.wmflabs.org/svgcheck/index.php Delphi234 (talk) 06:59, 30 July 2015 (UTC)

Same problem with this.

It looks like this problem has been here for a month now. Delphi234 (talk) 07:18, 30 July 2015 (UTC)

On my machine the original SVG files render just fine. It looks like some sort of bug with the server-side process that produces PNG thumbnails from the original SVG files. —RP88 (talk) 07:32, 30 July 2015 (UTC)

I can't say what's wrong but I can say that it also looks wrong when thumbnailed by the default currently installed version of rsvg on Toollabs. You can check this with User talk:Rillke/SVGedit.js (edit SVG, then preview). Perhaps it's due to 16:13 ori: depooled Precise image scalers (mw1159 / mw1160)to see if 2c9518ed78 helped. and we are running a new version of rsvg now? -- Rillke^(q?) 07:59, 30 July 2015 (UTC)

I am not sure how it displayed some time ago, but my first bet would have been some conflicting font-sizes in the uploaded files style id. Alexpl (talk) 09:18, 30 July 2015 (UTC)

These are all from the Template:SVG Chart and while it does not use any of the fonts we use, other files created from it do not have this problem. I see only 2 out of 127 that are affected. It does appear to be a change in how we do the rendering. Perhaps that can be fixed? Delphi234 (talk) 15:58, 30 July 2015 (UTC)

Well, none of them seems to have a font-size as tiny as 0,269 px. Alexpl (talk) 19:23, 30 July 2015 (UTC)

The width always seems to be 750 px. It has a scaling factor for both height and width, and the instructions say to use from 100 to 300 but I have successfully used 3000 I think. So far I can make it worse. File:Test.svg. Delphi234 (talk) 01:35, 31 July 2015 (UTC)

Theater programs

Is there any category for theater programs? I see we have a Category:Concert programs, but its only parent is Category:Concerts. Also, it has a subcategory Category:Recital programs, but based on its current content that's a useless catch-all. I would think there would be a general Category:Event programs or some such, and that it would also have subcategories for programs for sporting events as well. - Jmabel ! talk 17:21, 30 July 2015 (UTC)

By the way, this is the file that prompted the question. - Jmabel ! talk 17:26, 30 July 2015 (UTC)

cropped image won't display at full size

I cropped File:20100701 cthulhu poster.jpg to remove the underlying poster. (It is a photo of one political poster pasted over another, irrelevant one, and the orientation of the photo was close enough to orthogonal to make an easy lossless crop.)

It displays fine in thumbnails, both here and on WP-en and WP-fr. But it doesn't display at the top of its page, and when I click on it, I get a message that it cannot be displayed because it contains errors. All I did was use jpegcrop.exe, which is old and stable freeware I haven't had problems with before. Kwamikagami (talk) 19:50, 30 July 2015 (UTC)

I cropped it from the original and uploaded the version without errors. Ruslik (talk) 20:38, 30 July 2015 (UTC)

Thanks! Kwamikagami (talk) 01:57, 31 July 2015 (UTC)

July 31

27 million files

Right now, {{NUMBEROFFILES}} = 26,999,124. -- Tuválkin ✉ ✇ 07:17, 31 July 2015 (UTC)

Suggestions for finding a millionth file to upload

Hi, I'm in the process of drafting a WMF blog post sharing some case studies from my uploads, and need to choose a millionth image to upload in the next day or two. For ideas you can find a list of upload projects at User:Fæ#Projects. Suggestions welcome, I'm finding it hard to decide! --Fæ (talk) 07:42, 31 July 2015 (UTC)

Meaningless numbers only categories

Someone is systematicaly placing all files of train type categories in number subcategories such as Category:186 119. I have great doubts as to the usefullnes as having an individual category for individual locomotives. These numbers have no meaning and can even change as the nummering is reordened by a takeover. It is not unchangable as the IMO number of ships. At least add some meaning independant of the headcategory. For this case: (NS loc 186 119)Smiley.toerist (talk) 10:23, 29 July 2015 (UTC)

I don't think there is anything wrong with the principal of having a category for a single locomotive number, we also have categories for ships names as well as their IMO numbers and the names can and often do change over a hull's lifetime. I do however agree that the number should ideally be accompanied with some meaning as to what it refers to such as who owns the vehicle or what type it is. e.g. Category:British Rail Class 52 D1056 Western Sultan Oxyman (talk) 16:02, 29 July 2015 (UTC)

@Oxyman: In German MU consists the coaches are individually numbered, hence the classification system is flawed. And 80-90 percent of these numbers categories contain only one photo. This disables the gallery function of categories. -- KlausFoehl (talk) 08:50, 31 July 2015 (UTC)

I don't have a problem with one category per locomotive. But unfortunately, the user removes useful categories. For example, many locos had been placed into Loco type of Operator categories, so you could lookup rolling stock by operator. This has been removed in the big recat effort. --Sebari (talk) 23:39, 29 July 2015 (UTC)

Ditto, if the categories are named such that they are roughly intelligible. Numeric-only categories aren't, and I have warned this editor not to continue as s/he has been doing. Ideally, all these edits should be rolled back as they lose useful informatiom, and his categories mass-renamed or deleted. There used to be a "mass rollback" button for en:WP admins, but not here, unless anyone can tell me where this is? Cheers. Rodhullandemu (talk) 17:00, 30 July 2015 (UTC)

User has come back and done a whole load more unhelpful edits- so I've blocked for three days. Rodhullandemu (talk) 20:12, 30 July 2015 (UTC)

@Srittau and Rodhullandemu: I strongly agree with your assessment, this removal of useful categories. A mass rollback should happen soon, as already good faith edits occur to image page featuring these structurally vandalising edits. I also think that additional categories are an issue, albeit a minor one, but let's tackle the big issue first. -- KlausFoehl (talk) 08:50, 31 July 2015 (UTC)

Commons:Village pump/Archive/2015/07

NoScript warning when trying to view full size photo

Commons logo

Pulled the plug on CategorizationBot & ErfgoedBot

Template:PD-NL-Gov/en depreciated or not ?

Batch upload advice

Preview shows an image wrongly rotated

July 03

updated information suggest file name includes error

NASA picture

July 04

Study reports that Wikimedia Commons media has large financial value

Source information incorrect on an image

File transfer

Conversion of still GIF images using color or transparency to PNG

"taken with..."-Categories in the Categories of the camera manufacturers leads to heavy miscategorization

Electronics Categories

Computer Categories

Scanner Categories

eBay upload script wanted

Upload large files?

TIFF from LoC

User talk protection

July 05

Is there any policy against pages with a large number of images displayed?

Request for uploading a Flickr stream

World satellite map with political borders

Cross post - can a sculptor CC license a photo of a traditionally copyrighted artwork?

cat redirect question (Category:Memorials)

Problem with UTC time gadget.

July 06

Ambulance etc. categories

Tool for changing the descriptions of multiple images

SVGs as PNGs

Policy clarification needed for images with OTRS pending but no license

Wikidata update

"Sports clothing" and "uniforms"

July 09

Lossless files on Commons

July 07

FoP saved

July 11

Peer review and document improvement request

Central American / South American photos

Replace picture with watermark

Warped image?

July 12

Nicolas Henri Jeaurat de Bertry (1728–1796) request

July 13

hotcat-bug

Wikimania 2015

Unfair, arbitrary block (and in the middle of a discussion)

July 14

Upload wizard bug

July 15

Bigotry

Two files into one

Commons:Naming categories

Says it's public domain - but not 100% clear why?

Lua error in Module:Fallback

Images from historical books

Sorting by source book

Oddities

Progress reports

Photo's copied from facebook

Replica´s in Bermeo

July 18

Redundant

Use categories instead

Voting

Proposal to close

Category for ponor and losing stream

Christopher Michel

July 16

Broken history

Two-minute guide to still-life photography

July 20

Category:Photo taken with camera X type Y

big time problem in my file name APPLE I WATCH

The Use of Iloko language, spoken by over 1.5 million people in the Philippines and migrants the world over